SPKI

Last updated
December 7, 1998

Yulian Wang
Computer Science
Helsinki University of Technology
Yulian.Wang@hut.fi

Abstract

Table of Contents

1. Introduction

2. Motivation for Developing SPKI

2.1 A General Mechanism for Authorization

2.2 From Name-Oriented to Key-Oriented

2.3 Comparison to Existing Systems

3 SPKI Certificates

3.1 Certificate Structure

3.2 5-tuple Reduction

3.3 Using Certificates

3.4 SDSI Names

4. Evaluation of SPKI

4.1 Advantages of Public-Key Certificates

4.2 Does SPKI Meet Its Requirements?

4.3 Limitations and Open Questions

5. Conclusions

Glossary

References

1. Introduction

The Simple Public Key Infrastructure (SPKI) is a proposed standard for public-key certificates. This paper gives a general introduction to SPKI [1]. It will concentrate on main requirements of SPKI, how to construct SPKI certificates and the way they are used. Hopefully, it will help readers to further learn about the details of SPKI.

SPKI is an Internet draft that may be accepted as a standard by the Internet Engineering Task Force (IETF) in the future. In the year 1996, IETF SPKI working group started to write SPKI documents. The latest version of the draft was issued in November 1998 [1]. IETF will probably make the decision on the standardization next year (1999). First implementations of SPKI have already become available [2]. Commercial applications are expected to appear soon after the standardization.

SPKI is mainly used in access control. It emphasizes decentralization and using keys instead of names. Different permissions can be freely defined in SPKI certificates. The whole idea of SPKI certificates is based on public key cryptography. No matter whether in generating SPKI certificates, or in using them, private keys and public keys take main roles. In addition to being used in access control, SPKI certificates can be used as name certificates that provide a mechanism to get public keys according to names or attributes.

This paper begins by describing motivations for developing SPKI from real application requirements and history background in Section 2. Section 3 explains the structure of SPKI certificates and how they are used. SDSI (Simple Distributed Security Infrastructure) names are also introduced. Section 4 evaluates SPKI.

2. Motivation for Developing SPKI

How can Alice meet the requirements above? If Alice gives all users read,write and execute permissions to this directory, then everyone including Bob can read, write and execute the files. And if Alice removes the permissions after two days, Carol cannot access the files. If Alice creates a group consisting of Bob and Carol, then Bob and Carol always get the same rights. Alice cannot give Carol a write permission without giving Bob a write permission. The only other access control tool Alice has is her password. Definitely, she doesn't want to give the password to anyone else. What can she do?

Now suppose Alice has the right and possibility to make some certificates, which say "Bob has the right to read and execute the directory for the next two days, and Bob can also give some rights to his work team about this directory" and "Carol has the right to read and write the directory for the next two months, but she doesn't have the right to allow others to read or write to this directory". Suppose also that the operating system can accept and honor such certificates. Then Alice doesn't have the problem above.

Let's see another example. Acme Inc. has an account in a bank and this account is used to pay small purchases. Every employee has a password with which they can access the bank account. One day, Acme Inc. gets a large order. It hires some temporary employees, Alice, Bob, and Carol, who need to make some small purchases. Acme Inc. can not wait until the bank makes some passwords for those temporary employees, and also wants to give its employees different rights for accessing the bank account. Alice can make transactions of at most $100 at a time and Bob at most $20 at a time. The accountant Carol can only check the account balance. How can Acme Inc. cope with the requirements above?

Suppose Acme Inc. has a right to make some certificates for its employees, so that they will not wait for the bank to make passwords for them. Suppose also that in the certificates, Acme Inc. can define "Alice has the right to make transactions of at most $100 at a time, not before 12/12/1998, not after 26/12/1998", "Bob has the right to make transactions of at most $20 at a time, ..." and so on. When Alice pays a purchase from the bank account, she just sends her payment order with her certificate to the bank. The bank verifies her permission. If Alice's payment order is below her limit, the bank will allow her to do the transaction with the account. Otherwise, she will be refused. Thus Acme Inc. solves the problem above and runs its business more efficiently.

The required functions above are just what SPKI certificates can provide. SPKI certificates can be made according to different usages and distributed to users. From examples above, we can see the basic requirements of SPKI certificates.

Requirement 1. Freedom to generate. Everyone can freely issue certificates and delegate access rights to others. It should not only be possible for some central authorities or registered entities. In the examples above, Alice and Acme Inc. can generate those certificates without any other person's permission.

Requirement 2. Rights can be transfered. A person should be able to delegate his rights to his co-workers or agents. A company should be able to delegate its rights to its subsidiaries and employees. In the first example above, Alice gives Bob the right that he can give his friends the right to read the directory.

Requirement 3. Authorizations can be freely defined and distributed. In the certificate above, Alice can write the right of "read, write, delete" and so on. Those rights are defined by Alice. The rights "read, write, execute" are typical for file systems. They do not make any sense to banks. For banks, typical rights would be "check balance" and "transfer" etc. It should be possible to define new kinds of rights for every new application.

Requirement 4. Validity dates are clearly written in certificates. Most paper certificates like driver's license or credit cards have expiry dates. Similarly, it is wise to give electronic certificates only for a limited validity period.

2.2 From Name-Oriented to Key-Oriented

As we see, this kind of certificate is not directly related to access control. It just shows that someone owns this key. One important property of this kind of certificate is that it can only be signed by those few trusted keys.

As public key cryptography becomes more and more important in securing information technology, the question about how to get the public key according to certain names without being cheated becomes more and more important. In the real world, in most cases, we know a name or an attribute of an entity first, then we want to contact a person or a computer or other kinds of entities with this name (for example, "Acme Inc.") or this attribute (for example, "one who has paid"). So, we should be able to find a public key that belongs to an entity with the name or the attribute. Based on the digital name certificate and the public directory concept, X.500 and X.509 standards [4] were developed. X.509 supposes there is a single top certificate authority (CA) in the world. It can choose trusted entities and sign certificates to them so they become new CAs. The whole CA structure is like a tree and it is hierarchical. The bottom level CAs issue certificates to users.

There are some limitations in using the X.509 hierarchy. First, if the top CA makes a mistake in choosing trusted lower CAs, the lower level CAs might make false name certificates. Second, everyone who wants to use name certificates should belong to the same hierarchy. If one company wants to cooperate with another company, they should find another higher-level CA for them, so that certificates signed by one company can be trusted by the other one. It is not practical to find this kind of a CA. Third, X.509 assumes that every user has a unique name. In practice, we don't want to use such names. If one doesn't know his friend's distinguished name, he cannot find his friend's key from the X.509 directory. Fourth, for many reasons, people or companies don't want to let their employees' names become public.

All the problems of X.509 which are listed above indicate that it is difficult to have a perfect mechanism to solve the question about how to get public keys.

One important property of public keys is that they are globally unique. A public key can be very long. For example, a 1024-bit RSA key includes a random 1024-bit exponent. Thus a public key can be used to identify an object. For example, besides having a name, Bob can produce a public key and private key for himself. This public key can be used to identify Bob no matter how many people or other entities there are all over the world. Compared with a public key, a name has its limits. It is usually not unique globally. We can not be sure there is only one person whose name is Bob all over the world. We cannot use this name to identify our Bob globally. Usually, a name is used to identify an object locally. We may know that in our department, there is only one person called "Bob".

SPKI emphasizes public keys rather than names. Rights can be given directly to public keys. In this way, SPKI can avoid the problem of binding public keys and names.

Requirement 5. Largely use public keys instead of names.

Requirement 6. Provide a better mechanism for solving the public key finding problem. It will be a big improvement if SPKI can provide a better method than X.509 for how to find public keys according to certain names or attributes.

Figure 1.

As a system applying public key cryptography, PGP is mainly used to send a message though insecure channels. SSH is used to build secure channels form one computer to another computers through insecure networks. It is mainly concerned with rights and authority. SSL is used for secure web access.

In principle, any system applying public key cryptography can choose any type of name certificates. The one most suitable for the functions of the system will be chosen. It is possible that one type of public-key infrastructure are used in many systems. In practice, many systems use their own certificates. For example, PGP uses its own certificates to build a web of trust. SSL uses X.509 and many other certificate formats to certify the public keys of secure web servers. The goal of SPKI name certificates is to become a standard and to replace X.509 in many uses. The SPKI name certificates can be used with SPKI authorization certificates when authorization is given to any name instead of a public key.

One special property of SPKI certificates is that they often don't depend on any of name certificates because authorizations are usually given directly to keys. This property makes SPKI certificates more independent on the naming mechanisms and more free to be used. Similar freedom can be found in the existing system PGP. One big advantage of PGP is that when people want to communicate with others, they themselves can decide to accept those public keys or not. They don't need to wait until any CA (such as CAs in X.509) give out name certificates. This freedom makes PGP successful. Also the first requirement for SPKI given in this paper states that every user should have equal authority to generate certificates.

3 SPKI Certificates

The SPKI Internet draft is written by Ellison et al. [1]. The draft describes the proposed SPKI standard and the reasons for the design choices. Since Internet standards are open protocols, anyone is welcome to write their own implementations of SPKI. SPKI draft specifies only certificate formats. It is not mentioned which protocols will use SPKI certificates.

In Section 3.1, the SPKI certificate structure will be introduced. We concentrate on the main ideas. The details can be found in the SPKI draft. The use of SPKI certificates will be discussed in Section 3.2 and SDSI names in Section 3.3.

3.1 Certificate Structure

Figure 2. Certificate structure

The structure of an SPKI certificate is a signed message that contains five elements. The message without the signature is called a 5-tuple. These five elements are: issuer, subject, delegation, authorization and validity dates. Issuer and subject are mandatory elements, other elements are optional. All those elements are expressed in S-expressions which are specially used in SPKI and SDSI. S-expressions are a Lisp-like notation for defining message formats. There are standard rules for converting the S-expressions into binary format and back. The S-expressions and the conversion rules have the same purpose as ASN.1 and BER. SPKI does not use ASN.1 because S-expressions are more suitable for devices with small memory and slow processors.

The body which those five elements form is called a certificate. An SPKI certificate is signed by the issuer's private key.

There is a difference between a certificate and a 5-tuple. A certificate is a signed message, a 5-tuple is not. The relation between a certificate and a 5-tuple is like this: After the signature in the certificate has been verified, the certificate is stored in a computer memory as a 5-tuple. The signature of the certificate doesn't need to be stored. 5-tuple is used when a certificate is in the process of verification or reduction by a trusted computer program. After the signatures have been checked, if the computer that verifies certificates has a secure storage for the certificate data, it is not necessary to store the signatures. All the information with security relevance in the certificates is stored in 5-tuples. We can see it more clearly in Sections 3.2 and 3.3. The 5-tuples are also a kind of mathematical model of the certificates. The SPKI specification uses 5-tuples to define the semantics of the certificates.

The certificate is just like a license. With it the user can access a service. So all the rights and validity dates and who issues the certificates are clearly written in the certificate.

The main contents of a certificate will be discussed in the following. Those are the five elements (Figure 2) in a 5-tuple.

Issuer:	Issuer can be a public key or a hash value of the key. Issuer means who gives out the certificate, or who signs the certificate. The public key has a counterpart, that is the private key. They are a pair. The public key can be put on the issuer field and others can see it. The private key is used to sign the certificate. Since a certificate is directly issued by a key, names of people or computers are not mentioned here. Every certificate has to be signed except the certificate which is issued by the issuer to itself. Issuer doesn't need to be a person. Any entity which has a public key and a private key can be the issuer.
Subject:	Subject means who receives the rights given with a certificate. In the subject field, a public key or a hash value of a public key or a name is shown. That means this public key or the name owns this certificate and no one else can use it.
Delegation:	Delegation field indicates if the issuers gives the subject any right to redelegate the rights which the issuer gives to the subject. This field contains a boolean value. If an issuer allows the subject to give those rights to other subjects, the boolean value is true. According to the proposed standard, "propagate" is written in the certificate to show that the boolean value is true i.e. that the certificate holder has the right to redelegate the certificate.
Authorization:	Authorization means access rights. When issuer signs a certificate for a subject, it usually defines what rights the subject will have. Rights can be freely defined in certificates by certificate issuers. The contents of this field depend entirely on the application. Different applications define different access rights.
Validity dates:	Validity dates are used to define the validity period of a certificate by an issuer. The form of validity dates is suggested to use a not-before date and a not-after date.

SPKI certificates is based on public key cryptography. If a private key is lost or compromised, usually key revocation lists are maintained by some mechanisms. In SPKI, there is no this kind of large key revocation lists which are maintained by any central unit. Instead, every certificate issuer could mention the place where certificate revocation lists (CRL) are stored in the certificate [1]. But it is not a mandatory task. A certificate issuer can always give a short validity dates to the certificate to avoid damages brought by that a private key is lost or compromised.

If a subject gets the right to redelegate its rights, it can redelegate its certificates to other subjects. In addition, he can freely sign new certificates to other subjects. If the issuer also gives the right of redelegation to its subjects, then the subjects can redelegate their certificates further. In this way, certificates form chains. A subject can have a certificate chain that is composed by many certificates. This composition only limits a subject's rights since every step of further delegation, a subject can only get equal or less rights. The longer the chain is, the less rights the subject has. An example of a certificate chain is shown in Section 3.3.

Two things should be mentioned here: First, a subject can hold one chain of certificates for each purpose but, it can also hold several chains of certificates that give the same rights. For example, Alice signs a certificate to Bob and a certificate to Carol. Then Bob signs a certificate to Eric and Carol also signs a certificate to Eric. So Eric has two chains of certificates that start from Alice. If all the certificates have the same authorization, Eric can use either chain of certificates to show that it has the access rights. Second, the permissions given by an issuer to a subject are freely defined. For example, Alice's public key (Ka) gives Bob's public key (Kb) the permission to read her directory two days and also allows Kb to delegate the right; Kb redelegates the right that is issued by Ka to Carol's public key (Kc). Kb can also freely issue a certificate to Kc with permissions that are defined by Kb. For example, Kb can give Kc the following permissions: Carol can read Alice's directory for one week. Carol holds this set of certificates in her computer or some other storages. When Carol wants to access Alice's directory, Carol sends the certificates and her requests which are signed by Kc's private key to Alice's server. Alice's server grants the service if Kc has the rights to access the directory. The intersection of the rights and the validity dates are computed in the certificates. That tells how much rights go through the whole chain. Carol can never get more rights than Bob in accessing Alice's directory. The basic rule of computing this kind of access rights is the 5-tuple reduction that is illustrated in the next part.

3.2 5-tuple Reduction

Since the access rights are often expressed by a certificate chain, how to validate and simplify it becomes very important. When a person or a public key (called the prover) wants to access a service, it shows its certificates to the service provider's server. The server will accept the request if the prover has the proper rights. 5-tuple reduction is mainly used by a server to compute the rights of a prover. There a set of certificates can be simplified to 5-tuples after the server verifies their signatures. Then 5-tuple reduction rules can be used to calculate the prover's rights and further simplify the set of certificates to a single one.

The issuer can also produce a simplified Certificate Result Certificate (CRC) to the prover. The simplified certificate is issued directly by the service provider's public key. The certificate has exactly the same rights as the old set of certificates. Note that the server is assumed to be secure enough to hold the private key. Usually, it is not necessary to keep the private key in the server. It can verify the access rights with the public key. But the private key is needed for producing CRCs.

For example, a subject S1 has a certificate issued by the issuer I1 with the authority A1 and validity dates V1. Suppose S1 also gets the delegation right, that is D1 is true. This is expressed in 5-tuple as < I1, S1, D1, A1, V1 >.

Now S1 has the right to redelegate those rights to other subjects. Suppose S1 delegates the authorization A2 to a subject S2 with the validity dates V2. This is expressed in 5-tuple as < I2, S2,D2, A2, V2 >.

According the rule of reduction, these two certificates (a chain of certificates, with depth 2) are equal to one certificate that is expressed in 5-tuple as < I1,S2,D2,AIntersect(A1,A2), VIntersect(V1,V2) >. The reduced 5-tuple looks like a certificate that is issued by I1 to S2 with the authorization A1 intersected with A2, validity dates V1 intersected with V2, and with delegation D2. The 5-tuple can be written as an S-expression and signed into a certificate. So, in order to simplify a chain of certificates, the issuer I1 can directly issue a new single certificate to the subject S2. The certificate is signed by the issuer's private key.

Intersection of two or more authorization string expressions (AIntersect) always limits access rights. The more intersections there are, the more restrictions to the access rights. If the intersection is empty or the requested action is not in the intersection, then the prover's requests will be refused by the server.

The same happens to Vintersect. The validity period in the result 5-tuple is the intersection of validity periods of the two original tuples.

Validity dates are expressed as X = (Xmin, Xmax). Xmin is the not-before date and Xmax is the not-after date. When a verifier validates a set of certificates, it will calculate the validity dates for the set. They are expressed as V = (Vmin, Vmax).

V=Vintersect(X,Y) // X, Y are different validity dates.

Vmin = max(Xmin,Ymin), Vmax = min(Xmax, Ymax).

With the 5-tuple reduction rules, several purposes can be achieved.

a.	It can be used as a theoretical tool for defining the semantics of certificate chains.
b.	It is used by a server to compute the rights of a chain of certificates which are given by a prover.
c.	It can be used to simplify a chain of certificates.
d.	It can be used as a tool to protect the anonymity of the intermediate keys in a chain. The holder of a chain of certificates is able to read the intermediate issuers' rights. After simplifying a chain of certificates to a single one, the certificate holder can not read those rights any more. Note that besides reduction rules, encryption of the certificates and temporary keys can also protect the anonymity.

In the example of Section 2.1, a certificate issued by Alice's public key (Ka) to Bob's public key (Kb) looks like Figure 3.

Figure 3. Kb's certificate

When Alice' file server receives Bob's requests, it will verify the certificate and his requests before it allows Bob access the directory. The validation process can be implemented in many ways. In principle, it is as follows.

First, Alice's file server looks at the issuer field of the certificate to determine who issued it. Alice's file server finds that the issuer is Ka. In the file server's own ACL, it looks if Ka has the right to grant access rights. Ka has the right. Then the file server uses Ka to check if the certificate is really signed by Ka. If not, the requests are refused.

Second, Alice's file server looks at the certificate. The subject field's public key should be the same as the key that signed the request. The file server uses the public key Kb from the subject field of the certificate to check the signature on the requests. If the signature is not valid, the requests are refused.

The server does not need to know that the key Kb belongs to Bob.

Third, the requested service must be allowed for Ka in the server and it must be under the rights in the authorization field of the certificate. Alice's file server also checks the validity dates in the certificate. The certificate must be valid at the time of the request. If not, the request is refused.

Finally, after all these processes are done, Alice's file server is sure that Kb has the right to access the directory. Bob can read the directory now.

Note that public-key cryptography is an essential part in the process of using certificates. All certificates are signed with the issuers' private keys. When certificates are used, a user must send requests that are signed by the subject' private key. This is why SPKI has its name (PKI= Public Key Infrastructure).

All of the above describes the process of verifying a certificate. The following illustrates how the reduction rule is used.

Ka issues Kb a certificate and also allows Kb to redelegate its rights further. Kb decides to give Kc (Carol's public key) part of its rights. Thus Kb redelegates its certificate to Kc and signs a new certificate for Kc at the same time. Kc get two certificates which form a chain. See Figure 4.

Figure 4. Kc's certificates

The two example certificates above can be reduced according to the 5-tuple reduction rule into the five elements in the certificate in Figure 5. After using reduction, a verifier can sign a new certificate to a subject. In the example, Kc might get a new certificate as in Figure 5.

Figure 5. Kc's new certificate

3.4 SDSI Names

This section answers the question in Requirement 6 of Section 2.2: Does SPKI provide any better a mechanism to find out public keys according to names than X.509 and PGP web of trust? The SPKI working group has adopted SDSI names as part of the SPKI standard [1]. SDSI name certificates are used to find out public keys according to names or other attributes of entities. This part will introduce SDSI name certificates and show how they are constructed step by step.

SPKI certificates map directly to 5-tuples while SDSI certificates map to 4-tuples [1]. A name certificate is a signed message that defines a name for a public key or a hash value of the key. It can be represented by a 4-tuple. The elements of 4-tuples are: issuer, name, subject and validity dates. Name can be any byte string. Comparing to 5-tuples, the authorization field is replaced by a name and there is no delegation field.

The SDSI names do not need to be only names of people, they can be names of any entities or attributes of those entities. SDSI names can become very long because of a lot of references. For example:

Then how to find "Alice's boyfriend's sister"? First, we must know who Alice is. Then we can ask Alice who her boyfriend is. Then we can ask her boyfriend who his sister is. Note that here this boyfriend may have many sisters. But SDSI names don't need to be unique. If there are many choices for the entity with that name, it means all of them. If we delegate any rights to the sister, then any of the sisters can get the rights and use their rights.

SDSI names are divided into two parts: a chain of names and the entity who defines the name.

In our example: The name "boyfriend's sister" is meaningful to Alice (the principal saying it). In SPKI, principals are public keys.

This name has a well defined meaning. It means the "boyfriend's sister" for the entity that owns the key Ka. Since Ka is unique, the meaning of "boyfriend's sister " is well defined.

The way to find out "Ka's boyfriend's sister" is: First, find a name certificate signed by Ka. The certificate expresses: "my boyfriend is Kb" signed by Ka. Next, find a certificate that is signed by Kb that says "my sister is Kc". Those name certificates look as Figure 6.

Figure 6. Name certificate

Note that in the name certificates, validity dates are given. Alice might change her boyfriend, so the certificate signed by Ka has validity dates.

The whole SDSI name can be used as a subject in the SPKI certificates. In our example, we can delegate rights to "Ka's boyfriend's sister" which means to Kc.

If an authorization certificate is issued to "Ka's boyfriend's sister", then when the sister wants to use the authorization certificate, she must write a requests which is signed by Kc. In addition, she must prove the Kc is the public key of "Ka's boyfriend's sister" by sending the name certificates as shown in Figure 6.

When the server receives the whole package sent by Kc, it will validate Kc's rights. In this process, 4-tuple reduction is used. The server looks at the subject field and finds that the certificate is given to "Ka's boyfriend's sister". It uses the left certificate in the Figure 6 to reduce the name "Ka's boyfriend's sister" to "Kb's sister". Note here "Ka's boyfriend" was replaced by Kb according to the left name certificate. Then according to right name certificate in the Figure 6, "Kb's sister" is Kc. Thus the name in the subject of the authorization certificate is reduced to Kc. Note that 4-tuple reduction concept is different from 5-tuple reduction. There is no need to reduct name certificates themselves. 4-tuple reduction is only used when name certificates must be used with authorization certificates.

Note again that if the sister is not unique, then all sisters get the same rights. The authorization certificate is issued to any of the sisters, so, any of the sisters can use the name certificates and the authorization certificate. Also, we may trust Alice to have only one boyfriend but she could have many if she wanted to.

4. Evaluation of SPKI

This section will give SPKI an evaluation to see if it satisfies its requirements. We will also analyze its advantages and disadvantages.

4.1 Advantages of Public-key Certificates

One big advantage is that certificates can be published without any encryption. Certificates are signed by issuers' private keys. When a certificate is used, the prover must send a request that is signed by its private key. If any third part gets the certificate, he cannot use it since he doesn't have the relevant private key to sign a request. Only if the certificate holder doesn't want others to know its rights, it may hide the certificates. Only the certificate issuers and service providers know its rights. Another method that supports privacy of the subjects is that the subject can create a temporary key. In the certificates, issuers can issue rights to the temporary keys. This way, the subject cannot be recognized by looking at the key.

In a system that uses SPKI, every key holder holds a set of certificates. This kind of structure has some benefits.

First, every certificate user can use its certificates independently. For example, if Carol wants to use Kc's chain of certificates to access Alice's directory, Carol doesn't need to find Alice to pass her requests. Neither does Carol need to inform Bob, or to get the certificate again from Bob. Carol can send her requests directly to the server along with the certificates.

Second, the service provider doesn't need to store the long redelegation path in its computer. The redelegation path can be long and complex. If it stores the path, a large database will be needed and its maintenance will cost a lot.

Third, the certificates held by a subject can be freely composed into chains and the chains can be used to access services.

Finally, if a certificate in the chain expires or is revoked, the rest are still valid. Only this expired certificate needs to be replaced. It gives convenience to maintaining certificates.

Certificates can sometimes be used to replace traditional access control lists (ACL). The idea is not new to SPKI. Alice only needs to check all the information in the data Carol sent. She doesn't need to have a large database to store who has which rights (access control list). Of course, she needs to have a small storage for her own private key and public key. Besides, she doesn't need to spend time maintaining of the access control lists.

Traditional user authentication requires that user enters his name and then enters his password for access control. With SPKI certificates, the two steps above can be reduced into one step and automatically done by a computer. It is under the condition that a user is using his own workstation. A program in the computer can be used to send certificates to another server.

We summarize some benefits in using public-key certificates for access control.

Advantage 1: Certificates can be published and they are easy to maintain.

Advantage 2: Instead of using old ACL methods, the authorization certificates can be used more economically, through saving storage space and saving maintenance costs by distributing tasks to users.

Advantage 3: The certificates can be used to replace traditional user authentication after users are already logged in their own computer systems.

4.2 Does SPKI Meet Its Requirements?

Requirement 1. Most previous proposals for public key infrastructures mandate a centralized or hierarchical system of authorities. SPKI does not advocate any such structure. The key owners can have direct relations to the entities that they want to do business with. Anyone with a service in his control can start to issue certificates and give access rights to others as he wants.

Requirement 2. With SPKI certificates, the rights are transferable. A limitation of SPKI is that redelegation is either allowed or forbidden. There are no alternatives between the two extremes.

Requirement 3. The SPKI specifications do not say what kind of authorizations can be issued. It is up to applications to define what kind of rights they use and understand. SPKI does define some basic rules for how the rights are compared and gives some examples.

Requirement 4. The SPKI certificates have a validity period on them. In addition, there are some mechanisms for asking on-line confirmation and retrieving revocation lists.

Requirement 5. The whole idea of SPKI certificates and the way they are used is based on public-key cryptography. The public keys are in central roles. They take the roles that names have in most other systems. SPKI can be used completely without names.

Requirement 6. By adopting SDSI as one part of SPKI standard, SPKI is able to provide a new mechanism for getting public keys according to certain names. SDSI name certificates can also be used to get public keys according to attributes of entities. The names can be linked into long chains. So they can be used more flexibly than traditional name certificates. There are many paths ( many chains ) connecting to certain public keys. If the search through one path ( one chain) fails, other paths can still be tried. If one path is not trusted, other paths can be chosen.

SDSI name certificates emphasize decentralization. If one entity wants to get the public key of another entity, it can search for the public key according to a local name or attribute of the entity or names or attributes given by related entities. It doesn't need to rely on a globally trusted certification authority. This way, SDSI creates freedom.

4.3 Limitations and Open Questions

Furthermore, SPKI certificates have some limitations. Certificates can be long, so they must be managed by a computer or a special smartcard. Thus SPKI certificates can only be used after users have logged into their own trusted computer systems or used with other devices such as a special smartcard. For this reason, SPKI certificates cannot totally replace traditional user authentication mechanisms. A certificate can not totally replace a password.

How to control redelegation rights may also be a problem. In the first example in Section 2, Bob can redelegate his rights to anyone else. Alice cannot control it. For example, Alice doesn't want more than 10 persons in total to get the right for reading her directory. Or, Alice doesn't want Bob or Bob's friends to redelegate the rights to Carol. In this way, how to limit a redelegation power becomes a limitation of SPKI certificates.

However, SPKI certificates are a new tool that can be used in access control. It is unknown how popular it will be and what its main applications will be.

5. Conclusions

Glossary