Simple Public Key Certificate Carl M. Ellison
INTERNET-DRAFT CyberCash, Inc.
Expires: 22 September 97
Bill Frantz
Periwinkle
Brian M. Thomas
Southwestern Bell
17 March 1997
Simple Public Key Certificate
------ ------ --- -----------
Status of This Document
This document is a slightly modified copy of the draft dated 26
November 1996 which was not submitted to the Internet Drafts
directory. A second draft is in preparation at this time and will
supercede this one.
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 authors.
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
Ellison, Frantz, Thomas [Page 1]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
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, Frantz, Thomas [Page 2]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
Abstract
With the proliferation of public key cryptography on the Internet,
there arises a need for certification of keys. In the literature,
the word "certificate" is generally taken to mean "identity
certificate" -- a signed statement which binds a key to the name of
an individual and has the intended meaning of delegating authority
from that named individual to the public key. (See, for example, RFC
1422).
Establishing identity is not the problem of interest. A process
using public key authentication (telnet, ftp, an electronic commerce
server, etc.), and verifying a public key certificate in the process,
needs to check that the indicated key (i.e., the key holder) has
authority to access the controlled data or perform the requested
function.
An SPKI certificate is an authorization certificate. It grants a
specific authority to a public key rather than binding an "identity"
(such as a person's name) to that key. For example, one SPKI
certificate might grant permission for a given public key to
authenticate logins over TELNET as user CME on host CYBERCASH.COM for
some period of time.
For completeness, SPKI certificates are defined below which grant
"all authority of the indicated person" to a key -- and are therefore
identity certificates -- but it is not clear that those will be
needed.
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 [DNSSEC]. The inspiration we
received from the notion of CAPABILITY in its various forms (SDS-940,
Kerberos, DEC DSSA, [SRC-070]) can not be over-rated and we must
thank Butler Lampson for most of this inspiration.
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,
Paul Lambert, Jon Lasser, Jeff Parrett, Ron Rivest, Bill Sommerfeld,
Simon Spero.
Ellison, Frantz, Thomas [Page 3]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
Table of Contents
Status of This Document....................................1
Abstract...................................................3
Acknowledgments............................................3
Table of Contents..........................................4
1. Overview of Contents....................................7
2. Scope Of This Effort....................................8
2.1 Charter of the SPKI group..............................8
2.2 Areas Covered And Not Covered..........................8
2.2.1 Key and certificate storage..........................8
2.2.2 Protocols to use public key authentication...........9
2.3 Other Certificate Formats..............................9
2.4 Goals of this effort..................................10
2.5 Rejection of X.509 and ASN.1..........................10
2.6 Roles for Commercial Certification Authorities........11
2.7 CRCerts and Use of Non-SPKI Certificates..............11
2.8 Validation of Identity................................12
2.9 SPKI Certificates vs. Capabilities....................12
2.10 Chosen standard formats..............................13
3. Assumptions, Definitions and Design Issues.............14
3.1 Binding of key to principal...........................14
3.2 Directional Bindings in an Identify Certificate.......16
3.2.1 Address -> Key......................................17
3.2.2 Key -> Address......................................17
3.2.3 PGP key signatures..................................18
3.3 Meaning of a certificate..............................18
3.4 ACL versus SPKI Certificate...........................18
3.4.1 From ACL to Certificate.............................19
3.4.2 From Certificate to ACL.............................19
3.5 Certification chains..................................20
3.6 Source of a certification chain.......................20
3.6.1 Direct SPKI certificate.............................20
3.6.2 Certificate Result Certificate (CRCert).............21
3.6.3 CRCert as a Product.................................21
3.7 Role of Identity......................................22
3.8 Certificate Structure.................................22
3.9 Policy Structures.....................................23
3.10 Certifying Identity with SPKI Certificates...........24
3.11 SDSI: Global versus Local Names......................24
3.12 Certificate validity periods.........................26
3.13 Unwanted Attributions................................27
3.14 Secret Certificates..................................28
4. Certificate Formats....................................29
Ellison, Frantz, Thomas [Page 4]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
4.1 Certificate Fields....................................29
4.1.1 Subject.............................................29
4.1.2 Subject-Cert........................................29
4.1.3 Issuer..............................................30
4.1.4 Issuer-Cert.........................................30
4.1.5 <auth>..............................................30
4.1.6 <validity>..........................................30
4.1.7 <signature>.........................................31
4.2 Complex Policy Programs...............................31
4.3 Boundary lines BEGIN and END..........................32
4.4 Binary Format.........................................32
4.5 Date Format...........................................32
5. <auth> Field Examples..................................33
5.1 Delegation............................................33
5.2 Internet Access Control...............................33
5.3 Public Key Protected File System......................34
5.4 HTTP Access...........................................34
5.5 New <auth> fields.....................................34
5.6 SET Certificates......................................35
5.7 Identity Certificates.................................36
5.7.1 Authority flow from Name to Key.....................36
5.7.2 SDSI Name...........................................37
5.7.3 PGP-like Reference..................................37
5.7.4 Location Information................................38
5.7.5 Informational Self-binding..........................38
5.7.6 Dating Service Bindings.............................38
5.8 Authority to spend money..............................39
5.9 Comments to human readers.............................39
5.10 Group membership.....................................39
5.10.1 Authorization groups...............................39
5.10.2 SDSI groups........................................40
5.11 Other Certificate....................................40
5.12 Certificate for Blind Signatures.....................40
6. <validity> Fields......................................42
6.1 Expiration............................................42
6.2 Re-validation.........................................42
6.3 CRL...................................................42
6.4 Validity by Chained Hash..............................43
6.5 Session modifier......................................43
7. <signature> Field and Key Definitions..................44
7.1 Signature Format......................................44
7.2 Dual Signature Requirement............................44
7.3 Key Format............................................44
8. Examples...............................................46
Ellison, Frantz, Thomas [Page 5]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
9. Binary Format..........................................47
9.1 Tag definitions.......................................47
9.1.1 Non-auth fields.....................................47
9.1.2 Auth fields.........................................47
9.2 Integer format........................................48
9.3 Date format...........................................48
9.4 String format.........................................48
9.5 Algorithm definitions.................................49
9.6 Hash fields...........................................49
References................................................50
Authors' Addresses........................................52
Expiration and File Name..................................52
Ellison, Frantz, Thomas [Page 6]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
1. Overview of Contents
This document contains the following sections:
Section 2 describes the scope of both the SPKI working group and this
particular Internet Draft.
Section 3 gives necessary background for understanding the SPKI
certificate structure. It details assumptions, definitions and
design issues behind this structure design and is recommended reading
for anyone who did not follow the discussion on the working group
mailing list.
Section 4 describes the SPKI certificate formats -- listing the
fields in a certificate and giving two encoding methods: binary and
RFC822 in ISO 10646/UTF-8.
Section 5 describes SPKI <auth> fields. These are the meat of an
SPKI certificate, since they carry the authority or other information
being bound to a subject public key.
Section 6 describes SPKI <validity> fields. These have three
options, depending on whether one wants to use CRLs, short-expiration
or long-expiration to control the time period of certificate
validity. The three methods are shown to be functionally equivalent
but differing in performance.
Section 7 describes the SPKI certificate <signature> field.
Section 8 gives some examples of SPKI certificate chains for
practical uses.
Section 9 gives details of the binary certificate format.
The References section lists all documents referred to in the text as
well as readings which might be of interest to anyone reading on this
topic.
The Authors' Addresses section gives the addresses, telephone numbers
and e-mail addresses of the authors.
Ellison, Frantz, Thomas [Page 7]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
2. Scope Of This Effort
2.1 Charter of the SPKI 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.
2.2 Areas Covered And Not Covered
This particular draft is concerned only with certificate and
signature formats, using the certificates defined here both for
verification of identity and for proof of authorization. We do not
cover the other elements of a full public key infrastructure (PKI):
key/certificate storage and acquisition. We also do not cover all
the applications or protocols which must be modified to employ public
key authentication or privacy.
2.2.1 Key and certificate storage
There are several independent efforts at this time to provide a
database of keys or certificates for the Internet.
One, the DNS Security Working Group draft [DNSSEC], specifies an
efficient key storage and distribution mechanism. It may be possible
to store an SPKI certificate in a KEY Resource Record (RR) or to
Ellison, Frantz, Thomas [Page 8]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
create a new RR type for SPKI certificates, under the DNSSEC design,
but that effort has not been undertaken yet.
The PGP key server at MIT operating both as a web page and as an e-
mail driven service provides another example of efficient certificate
storage and retrieval for the net at large.
2.2.2 Protocols to use public key authentication
Proposals for modification of applications to employ public key
authentication are proceeding independently, e.g., [PKLOGIN]. We
expect to write drafts detailing the use of SPKI certificates for
each of these specific applications, one at a time, but encourage
other developers to do so independently as they develop strong
authentication protocols or applications using public keys for
confidentiality.
2.3 Other Certificate Formats
We are aware of a number of actual and proposed kinds of signed
public keys which, by some definition, qualify as certificates:
1. PGP signed keys
2. X.509 identity certificates, from a number of sources
3. X.509 SET (Secure Electronic Transaction) certificates
4. DNS Security Extension signed keys
It is not our intention to coerce these other certificate formats
into our mold, although they are welcome to switch over. The
certificate structure defined below is flexible enough to accommodate
all of the above.
However, we recognize that a real world system will involve some
mixture of SPKI and non-SPKI certificates as well as traditional
Access Control Lists (ACLs). Our design accommodates these through
the Certificate Result Certificate process, allowing all these to be
merged into a single, simple format as far as application software is
concerned.
Ellison, Frantz, Thomas [Page 9]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
2.4 Goals of this effort
In keeping with the design goals enumerated in section 3 of RFC1958,
it is our goal to keep the SPKI certificate pruned to the minimum
information necessary to accomplish the job at hand -- which is
secure authentication and authorization of access control and
confidentiality for the Internet. We use well tested formats with a
long history of success and have chosen those which require the bare
minimum of tool software so that applications remain as small and
efficient as possible. We offer the bare minimum of options, in
order to reduce program size and complexity.
We also recognize that some kinds of certification (such as notarized
identity certification) can carry risks of invasion of privacy for
the individual. We have therefore designed these certificates to
reveal the minimum information necessary to get the job done,
whatever that job happens to be. In many cases, the user can remain
anonymous in the traditional sense while exercising strongly verified
authorization.
2.5 Rejection of X.509 and ASN.1
For several years certification has been assumed to mean use of X.509
identity certificates with their intricate ASN.1 formulation. We of
the SPKI working group have observed that X.509 suffers from several
failings, many brought on by the use of ASN.1. We also believe that
any use of ASN.1 requires either difficult hand coding or the use of
a large and sometimes costly ASN.1 compiler.
Although the subjects of ASN.1 and X.509 have led to protracted
debate on the SPKI list and elsewhere, we have made a decision to
stop our own participation in the debate and avoid both X.509 and
ASN.1 in the certificate structure presented here. Although the SPKI
certificate format can be considered an alternative to X.509, its
main value in our eyes is as both a simplification and a
generalization of the certificate concept rather than as a mere
change of format.
Those who wish background information on this decision can consult
the SPKI archives (through majordomo@c2.org).
Ellison, Frantz, Thomas [Page 10]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
2.6 Roles for Commercial Certification Authorities
Current commercial certification authorities (CAs) generate X.509
certificates but our rejection of X.509 should not be construed as a
rejection of the role of commercial CAs. A CA has a definite role to
perform, in some circumstances.
What a CA offers is not a mere X.509 facility. Rather, it offers a
carefully crafted policy statement, published for the world to read;
well engineered physical plant security and personnel security;
careful processing of individual transactions, etc. These attributes
are independent of certificate format. A commercial CA could issue
PGP certificates or SPKI certificates as well as X.509, should the
market demand these other formats with the level of assurance a
commercial CA offers, granting some authority delegation the CA is
qualified to perform.
2.7 CRCerts and Use of Non-SPKI Certificates
Few certificates live in a vacuum. Most relate to some other
certificate so that the process of validating a certificate involves
validating a thread or sub-mesh of certificates embedded in a
connected mesh. We expect some certificates in such a thread to be
non-SPKI. At the same time, we desire to save application developers
from having to parse all the various certificate types (especially
X.509).
The result of certificate validation can be a single access
permission but in the process of performing a validation, the
verifier has determined and can record a period of time during which
the same answer will occur (because none of the certificates and CRLs
involved will have expired). The verifier can therefore cache the
certificate result with its own expiration time. It can also sign
that certificate result cache entry, to generate an SPKI certificate
giving the specific access permission to that key for that period of
time. We call this last process the generation of a Certificate
Result Certificate (CRCert). The CRCert is presumably valid only at
the verifier itself or possibly its siblings.
This process opens the possibility that a large enough site could
maintain a single trusted machine capable of evaluating non-SPKI
certificates and elaborate policies, yielding single SPKI
certificates which the working servers actually check, saving them
the code to understand all certificate formats and policies.
Ellison, Frantz, Thomas [Page 11]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
2.8 Validation of Identity
"Without a KMI [Key Management Infrastructure] of trusted
certificate authorities, users cannot know with whom they are
dealing on the network...." [IWG]
"..identity-based certificates create an artificial layer of
indirection between the information that is certified (which
answers the question "who is the holder of this public key?")
and the question that a secure application must answer ("can we
trust this public key for this purpose?")." [BFL]
An SPKI certificate delegates authority directly to a public key. It
is the responsibility of the delegator of that authority to verify
the identity of the key owner, if that is important, prior to issuing
an SPKI certificate. The identity thus determined need not be
represented in the certificate itself beyond the <subject> public
key.
Traditional identity certificates could have a role at this step but
it is not always necessary to use identity certificates to validate
identity. [IDENT] (See section 3.6.1 for a discussion of bypassing
identity certificates.)
It is also not always sufficient to validate identity through an
identity certificate. Any substantial pool of users will include
those with the same common name. Therefore, some information needs
to be added to those names to make them unique before identity
certificates can be issued. The information added may not be known
to the person or entity validating the certificate in question,
leaving the verifier with an ambiguous (and therefore worthless)
identity mapping. Only if the subject of an identity certificate
communicates his unique name over a secure and pre-authenticated
channel to the certificate verifier, can the verifier know which
certificate to honor for the intended person -- but if that process
is followed, the subject can communicate his public key over that
same secure, pre-authenticated channel and avoid certificates
entirely.
2.9 SPKI Certificates vs. Capabilities
An SPKI certificate is closer to a "capability" as defined by Butler
Lampson et al. than to an identity certificate. There is the
difference that in a capability system, the capability itself is a
Ellison, Frantz, Thomas [Page 12]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
secret ticket, the possession of which grants some authority. It is
anonymous (cash rather than a check). Therefore, if you grant
authority to read a capability, you have delegated the ability to use
it. An SPKI certificate identifies the specific individual or group
to whom it grants authority and therefore the ability to read the
certificate grants no authority and the certificate itself does not
need to be as tightly controlled.
2.10 Chosen standard formats
We have adopted a stream-oriented binary format, easy for parsing in
normal languages such as C. We provide (in a separate file) C
programs for translating from binary format to RFC822 style format
and back.
We recommend using ISO 10646/UTF-8 for all text, since it includes
ASCII as a subset and if the text fits within ASCII, no difference is
noticed.
We have kept options to a minimum, to simplify parsing and use of
certificates.
We provide some <auth> field definitions which we know will be useful
but leave open a method for application programmers to define new
<auth> fields as the need arises. As such become popular, we plan to
amend this document to define tag fields and specific formats for
those new <auth> fields.
There was a strong move, inspired by [SDSI], to use S-expressions as
the readable format. S-expressions provide some interesting
possibilities, especially when programs are part of the certificate
(as with [BFL]), but we have chosen not to require their use for fear
of forcing all applications to implement list-processing primitives.
Ellison, Frantz, Thomas [Page 13]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
3. Assumptions, Definitions and Design Issues
There were a number of discussion topics involved in the design of
the SPKI certificates and we summarize them here for the reader who
was not part of the SPKI discussion. This section should at least be
skimmed by even the reader with a solid grounding in classical
(identity) certification. Some of these might be new concepts. Some
provide definitions for terms which traditional discussions of
certification frequently leave undefined.
3.1 Binding of key to principal
The most important issue is the notion of the binding of a key to a
principal.
By PRINCIPAL, we mean an entity (e.g., person, processor,
process, device (such as a printer), ...) which supplies a
service or requests action in a distributed computer system.
Discussions of certification frequently speak of binding of keys to
an "identity" (specifically, under X.509, to a Distinguished Name) as
if the "identity" were the same as the principal and as if the
identity certificate accomplished the binding of key to principal.
We observe that the binding between a public key and a principal has
nothing to do with certificates. Here we distinguish between a
principal and its name or "identity", however one defines that latter
term.
For any public key cryptosystem to work, it is essential that a
principal keep its private key to itself. In the case of a human
being, this might involve keeping the private key encrypted under a
high-entropy passphrase and storing it only on the person's own
personal computer or floppy disks. Some humans might even keep the
private key in a tamper-resistant PCMCIA card which will never
release it and will in fact destroy it after too many failed attempts
to gain access. In the case of a network node, this might involve
keeping the private key in a tamper-resistant cryptographic processor
which generated it and which will destroy it if tampering is
attempted.
If the principal does not keep the private key protected (if the
private key gets out to others to use) then one can not know what
entity is using that key and no certificates will be able to restore
Ellison, Frantz, Thomas [Page 14]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
the resulting broken security.
Therefore, we are forced to assume that all private keys are kept
private and bound tightly to the one principal to which they belong.
We will have to provide for methods of announcing the compromise of
such private keys whenever this assumption proves false, but we must
assume that unless such notification is delivered, each private key
is secure and attached to its owner.
Note: We have specifically included the possibility for a holder
of authority to delegate that authority on his own, in order to
reduce if not eliminate the motivation for one principal to loan
a private key to another.
We do not expect every person, process and device in the Internet to
employ true tamper resistance. Many people will keep and use private
keys on an insecure personal computer or workstation. However, we
are forced to assume protection of the private key or give up any
notion of cryptographically strong authorization tests.
This assumption binds a key to one principal. That key is then a
surrogate for the principal, in cyberspace. In the language of
[SRC-070], the key speaks for the principal. This is true even
without establishing the identity of that principal in any other way.
That binding of key to principal does not require any certificates.
It is a tautology. For each key, there is one principal, identified
as "the keyholder".
The keyholder has sole possession of the private key by definition
and could be identified by that key, but that key is secret. There
is only one private key to match a given public key, so the keyholder
can be identified by the public key just as uniquely. Similarly,
there is only one public key which hashes to a given secure hash (by
definition of "secure hash", assuming we are limited in computation
power), so the secure hash of a public key can also be used to
identify the keyholder.
DEFINITION: Keyholder -- a principal who holds a given private
key. The private key is indicated by either its corresponding
public key or a secure hash of that public key. Every key has a
keyholder, by definition. There is no implication in the word
"keyholder" that anything else is known about this principal
except the fact that it holds the indicated private key.
Ellison, Frantz, Thomas [Page 15]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
Without certificates, we might not know anything else about the
principal (such as name, gender or even if the principal is a living
being) but we do know enough to link together separate messages from
the same principal. For some purposes, that is sufficient
identification (for example, when a person is first encountered on-
line via signed messages and there is no intention of linking that
person to any physical being, only to his or her own other messages).
However, there are other applications for which the ability to link
together separate messages from an anonymous source is not adequate
and therefore for which certificates are required.
3.2 Directional Bindings in an Identify Certificate
When the authorization is specific (e.g., "the keyholder is permitted
FTP access to FTP.CLARK.NET as user CME"), the nature of the
delegation of authority is clear. However, when a certificate is
used to bind identity in some form to a public key, as frequently
occurs in the traditional certification literature, there is
sometimes confusion about what is specifically being delegated.
There is some transfer of authority between the named principal and
the public key, but the direction of that transfer is left
unspecified.
The traditional certification literature was written in the days
before cyberspace exploded. In those days, all relationships and all
authority were in the physical world and therefore any transfer of
authority was from the physical world into cyberspace. Certificates
of that time were assumed to transfer authority from a named physical
entity to a public key.
Now that a significant number of persons are on-line, it has become
common for people to establish relationships on-line. Any authority
tied to those relationships lives in cyberspace and if it is to be
linked to a physical entity, a certificate would transfer the
authority from a public key to a physical entity.
With the addition of this flow of authority from cyberspace to
physical space it is important to recognize that bindings are not bi-
directional. It is imperative that an identity certificate capture
the direction of the flow of authority.
Take for example a certificate binding a public key and an e-mail
address.
Ellison, Frantz, Thomas [Page 16]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
3.2.1 Address -> Key
That certificate might be intended to mean: "The person who is known
to the world as the one who logs in and exchanges mail as xxx@yyy.zzz
has the indicated key." In this case, authority flows from the e-
mail address (as a name for a physical being) to the key and the
certificate should be signed by the system administrator responsible
for that e-mail address creation.
This is precisely the situation with [DNSSEC]. In this case, we must
be concerned about the care with which the zone owner verified
possession of the private key by the indicated user as well as about
the general trustworthiness of the zone owner.
In general, we note that when authority flows from physical
space into cyberspace, one must establish trust in the physical-
space entity delegating that authority. This leads to the real
work, legal contracts and expense of a commercial Certification
Authority establishing trustworthiness and being explicit about
the process used to verify the identity and key of the key
holder. The only sure way to bypass this risky and complex
process is when the physical space entity is one's self -- that
is, when one generates his or her own certificates.
3.2.2 Key -> Address
That certificate might be intended to mean: "I, the person bound to
this private key, can receive encrypted mail at this e-mail address".
In that case, authority is flowing from the key (as surrogate for the
(unnamed) principal) to the e-mail address and the certificate should
be signed by the key itself. We can trust this statement without
qualification because the owner of the key is the final authority on
where he or she can receive e-mail. There is no motivation to lie
about this. Mail sent to the wrong place will not reach the
keyholder and the person it does reach will not be able to decrypt
it.
In general, we note that when authority flows from cyberspace
into physical space, a key itself is usually a final authority
and certification is then relatively simple and secure.
Ellison, Frantz, Thomas [Page 17]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
3.2.3 PGP key signatures
In the case of PGP, which usually binds keys and e-mail addresses, it
is probably the (Address->Key) interpretation which users assume
although the signers are not the owners of the appropriate DNS zone,
so they are not authorized to make the statement they are assumed to
be making. PGP attempts to make up for that lack of authorization by
allowing multiple witnesses to sign a key.
Common practice with PGP calls for the owner of the key to sign the
association (UserID,key) also -- in which case the (Key->Address)
interpretation holds as well, although that interpretation is usually
overlooked by PGP users.
3.3 Meaning of a certificate
As shown in the PGP example above, identity certificates rarely have
explicit meanings. RFC1422 certificates had meanings specified in
part by a policy statement on file in the office of a PCA (Policy
Certification Authority). However, those meanings applied to an
entire zone of a tree of certificates and could not specify for each
certificate the direction of transfer of authority, as in the example
of the previous section.
More to the point, those identity certificates were not intended to
delegate any specific authority, as SPKI certificates are.
We have chosen to make the meaning of a certificate explicit as a
required field in each certificate. Since an SPKI certificate
transfers authority to a key, the meaning field is referred to here
as <auth> and must specify the specific authority being delegated by
the certificate. If the certificate is an identity certificate, the
direction(s) of transfer of authority is specified as well.
3.4 ACL versus SPKI Certificate
An Access Control List (ACL) is a mapping from some named principal
or named group of principals to one or more access permissions. If a
principal is identified only via an identity certificate, any process
faced with a request to give access to that principal must also check
an ACL or its equivalent to determine whether or not to grant access.
The ACL is central to secure operation and must itself be kept very
securely. The ability to write an ACL, in systems which use them, is
Ellison, Frantz, Thomas [Page 18]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
the ability to have any access to the controlled resource.
3.4.1 From ACL to Certificate
A process or device which grants access can keep an ACL in protected
storage. As long as this is possible, the straight ACL is a very
efficient mechanism.
If the ACL were to grow beyond the capacity of protected storage or
if it would need to be shared with sibling processes or devices, then
it might need to be protected cryptographically by digital signature.
One can digitally sign an entire ACL, for example to back it up in an
insecure place. Alternatively, one can sign individual ACL entries.
In both cases, the signature key used is that of the process or
device which owns and must trust the ACL. No certification of that
key is necessary, as long as the same process both generates and
reads ACL entries.
If individual entries are signed and if the semantics of an ACL is
independent of order of its entries, then the signed entries can be
given individually to the principals to whom they grant access.
Those principals are specially motivated to preserve their own ACL
entries and present them to the verifier when requesting access. For
large ACLs, this could substantially reduce the data management
burden of an access-granting process.
The builder of an ACL has a choice of how to name the principals
involved. One choice is to use a key or its hash to identify the
keyholder. A signed ACL entry of that form is an SPKI certificate.
3.4.2 From Certificate to ACL
An SPKI certificate grants a specific authority to a key. Once a
verifying process reads such a certificate, it must validate it (by
checking its signature) and probably validate a chain or mesh of
authority certificates in order to determine that the delegation can
be trusted.
Once the verifier has established that trust, it can generate what we
call a Certificate Result cache entry -- a data structure kept in
trusted memory, noting the delegation of the given authority to the
given key. That cache entry is equivalent to an ACL entry, using the
key as a name for the principal. If that cache entry is then signed
Ellison, Frantz, Thomas [Page 19]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
and returned to the supplicant as an SPKI certificate, we call the
result a Certificate Result Certificate (CRCert).
3.5 Certification chains
A single certificate is often not adequate to provide assurance that
the given principal is authorized to receive the access or service it
is requesting. The certificate grants or delegates some authority
from an issuing key to a subject key. This leaves open the question
of whether the issuing key has the authority to perform that grant or
delegation. Unless the issuer is the same entity as the verifier of
the certificate, this latter authority needs to be checked via a
certificate or ACL entry.
3.6 Source of a certification chain
There can be only one source of a chain of authority: the verifier of
the certificate chain. Even if the world may think there is a
globally recognized source of a chain of authority delegation, that
source must be trusted or not by the certificate verifier. That
declaration of trust calls for a certificate (or ACL entry, if memory
is adequately protected) issued by the verifier, making the verifier
the source of the chain.
Under this model, all verifiers are at least potentially also issuers
of certificates. There are two cases in which this might be
literally true.
3.6.1 Direct SPKI certificate
A verifier (or the system administrators who control a verifying
process) can issue direct SPKI authorization certificates for a given
public key. (We anticipate this being a very common occurrence.)
For example, one often gets a corporate account on some workstation
or LAN by physically appearing at the office of a corporate system
administrator and being introduced as a new employee. The employee
chooses a login name and a new account is created with a password to
be changed on first login. During this process, the new employee
could present not only a choice of login name but also a public
signature key -- and the system administrator could generate an SPKI
TELNET and FTP certificate for the new user on the spot.
Ellison, Frantz, Thomas [Page 20]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
For another example, one normal process of setting up a home ISP
account involves filling in an on-line form, over a dial-up line,
with or without custom software running on the user's PC to do the
registration. That form typically communicates a credit card account
number to be used to pay the ISP's monthly service fees together with
whatever identifying information is needed by the credit card
company. One could provide a public key at the same time, in the
same form, and have the ISP generate the SPKI certificate for access
appropriate to the kind of account being purchased.
3.6.2 Certificate Result Certificate (CRCert)
As noted in Sections 2.7 and 3.4.2, the process of verifying
permission to gain access might involve the testing of multiple
certificates -- perhaps an identity certificate chain as well as an
authorization certificate or set of them, representing signed ACL
entries. Once that process is complete, the verifier has a single
result -- positive or negative. If the result is positive, the
verifier can also know the validity period of that result.
This information can be cached by the verifier as an ACL (with
expiration time) or converted into an SPKI certificate, issued by the
verifier. We refer to such a certificate as a Certificate Result
Certificate or CRCert.
Examples of CRCert formation are given in Section 8 of this document.
3.6.3 CRCert as a Product
One use of a CRCert is to convert from one certificate format to
another. For example, one might invest in an X.509-aware certificate
processing engine but not wish to burden all access-granting
applications with that volume of code and with the validation of
chains of certificates. CRCerts give the option of validating the
X.509 certificate chain in an off-line process within the same
facility as the access-granting application and reducing that chain
to a single CRCert which expires at the time of the earliest
certificate (or CRL) of the chain. That CRCert is valid only within
the trust domain of the key which signed it -- typically a single
computing facility or LAN -- but can be used in place of the full
certificate (and ACL) chain.
One might even set up a commercial enterprise whose purpose is the
translation of certificates, certificate chains and CRLs into SPKI
Ellison, Frantz, Thomas [Page 21]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
certificates, but of course one then introduces the question of trust
of this commercial enterprise.
3.7 Role of Identity
The fact that a verifying process cares only about a specific
authority delegation to a specific key has led the design of an SPKI
certificate to provide precisely that information. However, there
are other activities which care about the identity of the principals
involved. There is likely to be an audit log, for example, in which
all accesses are recorded and that log may need to be interpreted by
a human security officer whose desire is not to grant access but
rather to locate a given principal in physical space.
SPKI permits relatively anonymous secure access but it does not
require anonymity. A number of certificate options are presented
below for mapping from a key to an individual principal in physical
space. These mappings, by themselves, do not delegate authorization
so they are considered informational. One could imagine policies for
granting access which require the existence of such a location
certificate as part of the principal's certificate package but we
give no examples of such policies.
3.8 Certificate Structure
An SPKI certificate has five conceptual fields:
ISSUER: the public key of the issuing party, both as a means for
verifying the certificate signature and as a name for the
issuing principal.
SUBJECT: the public key receiving authority via this certificate.
AUTHORITY: the specific authorization(s) being delegated in this
certificate. Section 5 gives details about <auth> fields.
VALIDITY: at least an expiration date but possibly a more complex
procedure for determining certificate validity. Section 6 gives
details about validity fields.
SIGNATURE: a signature by the issuer (and, optionally, by the
subject) of the fields above. Section 7 gives details about
signature fields.
Ellison, Frantz, Thomas [Page 22]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
A valid certificate can be represented by three quantities:
(<issuer>,<subject>,<auth>)
and by reference to these, policy structures can be constructed.
This certificate is taken to mean that "<issuer> says that <subject>
has attribute <auth>", where <auth> is typically a specific
authorization.
One could form indirect certificates as well, of the form:
(<issuerA>,(<issuerB>,<subject>,<auth>))
meaning "<issuerA> says that <issuerB> says that <subject> has
attribute <auth>", but we do not advocate such constructs -- instead
preferring <issuerA> to establish enough trust in <issuerB> to be
able itself to assert the <subject>'s permission and map that
construct into:
(<issuerA>,<subject>,<auth>)
3.9 Policy Structures
[BFL] introduces a language called PolicyMaker in which one can
express security policy statements -- the specific certificate
requirements by which a given action will be authorized. The actual
requirements are written in a safe language which program is then
bound to a key or set of keys by an issuer's signature.
It is possible to include a PolicyMaker assertion or policy as an
<auth> of an SPKI certificate. However, we leave that activity to
the authors of [BFL].
In a separate document, we describe a simple language consisting of
lines of the form:
(<issuer>,<subject>,<auth>)
where <issuer> and <subject> can be:
1) internal variable names to indicate equality of keys between
certificates;
2) explicit keys; or
3) parameter names
to allow specification of simple policies to cover most cases. These
Ellison, Frantz, Thomas [Page 23]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
lines would be interpreted much as one interprets a PROLOG program,
but are much more tightly constrained, to simplify both understanding
and execution.
If such a program occurs as the <auth> of an SPKI certificate, that
certificate constitutes a promise by the <issuer> to grant access (or
generate a certificate granting access) in return for certificates
satisfying the templates.
Such a process was mentioned in sections 2.7, 3.6.2 and 3.6.3 above.
However, this signed policy statement (or one in PolicyMaker) gives
the advantages:
1) that the interpreter does not have to store all such policy
statements;
2) that a single processor can generate CRCerts from a wide variety
of policies; and
3) that the user of that CRCert processor can know ahead of time
exactly what certificates to present and can pre-validate them.
3.10 Certifying Identity with SPKI Certificates
It is possible to certify identity with an SPKI certificate, although
we are skeptical about the value of a traditional identity
certificate (cf., section 2.8).
Section 5.7 includes <auth> lines for establishing and making
explicit the common kinds of identity association.
3.11 SDSI: Global versus Local Names
[SDSI] recognized that all names are local, even those generated by
an allegedly global CA. More importantly, for a name to be
meaningful, it must be known by the person or program using it (the
verifier) and unambiguously associated by that verifier with the
person or object (the subject) to which it refers. In the case of a
person as verifier, this name space is inherently limited in size and
complexity by the capacity of a human memory.
SDSI achieves a global name space by linking together local name
spaces. That is, two people, Alice and Bob, may each have a friend
they call Carol. To each of them, the name (carol) is used. If
David knows both Alice and Bob, then David might have occasion to
speak with each of them about Carol. Not necessarily having met
Ellison, Frantz, Thomas [Page 24]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
Alice's or Bob's Carol, David uses the names (alice's carol) and
(bob's carol).
David might be able to tell that Alice and Bob know the same Carol by
inspecting the certificates issued by Alice and Bob for Carol:
(K-alice,K-carol,"(carol)")
(K-bob,K-carol',"(carol)")
If K-carol = K-carol', then Alice and Bob know the same Carol.
However, Alice and Bob are free to reorganize their local name spaces
at will, without notifying anyone who might have learned name
mappings, so this equality of keyholders can be considered valid only
for the shorter of the two certificate validity periods.
Under SDSI, a name might be an individual or it might be a group.
One could think of an individual as a group of one member, in which
case all SDSI names can be thought of as groups. The entity defining
that name is responsible for issuing certificates binding a <subject>
key to the name or declaring that the principal (the <subject> key)
is a member or not a member of the named group.
As names get communicated from entity to entity, they get longer (not
unlike UUCP delivery addresses). The "'s" of the examples above is
only for human consumption and is not actually present in a SDSI name
-- so one might have a name, for example:
(carl jon zorak)
which identifies a keyholder also known as
(tom mary kathleen)
if the keyholder's given name were Kathleen and Jon's nickname for
her were Zorak.
The binding of a key to a SDSI name requires a certificate for each
name in the list, issued by the preceding entity. That is, if the
verifier has key K0 and Kathleen(=Zorak) has key K1, the example
above would include certificates:
(K2,K1,"(zorak)")
(K3,K2,"(jon)")
(K0,K3,"(carl)")
(K4,K1,"(kathleen)")
(K5,K4,"(mary)")
(K0,K5,"(tom)")
Ellison, Frantz, Thomas [Page 25]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
and might include certificates such as:
(K0,K1,"(carl jon zorak)") or
(K3,K1,"(jon zorak)")
although those latter certificates should be valid only for as long
as the shortest validity of the underlying certificates.
3.12 Certificate validity periods
Our experience with credit cards has influenced the way we consider
validity periods of certificates.
A credit card is issued with an expiration date 1 to 3 years later
than the date of issue, yet one can revoke a credit card and have
that revocation be effective within a day of the request. That
credit card has a validity period of one day (or less) in spite of
its expiration date.
At one time, credit card validity was verified at a checkout counter
by looking the card number up in a book of revoked cards. The
validity period of a card not listed in such a book was the time
until that book was updated and the card had to be looked up again.
This practice has migrated into the digital world through the CRL
(Certificate Revocation List) construct.
Modern systems accepting credit cards perform an on-line validity
check, in which case the validity period can be very short and is
determined by the time it takes to make a database update from a
report of a lost or stolen card.
An authorization certificate can be stored in read-write storage,
since it is protected from tampering by its digital signature(s).
Therefore, it has a third option for short-term validity checks. It
can hold a guaranteed validity time which is re-written as needed
during an on-line check, but can be trusted without the on-line check
until that time.
All of these methods of validity checking are functionally equivalent
but they have different performance impacts.
CRL:
If one can afford to keep a copy of the CRL, there is the
communications load of accepting periodic additions to the CRL
(hopefully very small and relatively infrequent). Each
verification then requires a local memory reference.
Ellison, Frantz, Thomas [Page 26]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
If the CRL must be delivered by the supplicant or fetched from
an on-line source with each verification, then the
communications load of CRL usage is proportional to CRL size and
can become very high.
On-line:
The communications load for on-line checking is constant.
Periodic-revalidation:
If a certificate is used more than once during its validity
period, periodic-revalidation provides a caching effect, saving
the communications load for on-line checking. It also permits
the supplicant to perform the on-line check and distributes that
load away from the verifier.
Because of the time it takes to communicate and the need to allow for
clock skew, a validity period can never go to zero. The shorter the
period, the less risk an issuer runs of having a withdrawn
authorization active in the world. The longer the period, the less
communication and revalidation overhead is incurred. Choice of
validity period is left up to the issuer of the certificate.
3.13 Unwanted Attributions
There is a potential problem that a certificate might be issued which
the keyholder does not want.
For example, a keyholder, Alice, has a signature key, K, being used
to sign digital lab notebooks for later use in patent applications.
That key is certified as hers by her company through an SPKI identity
certificate with an EMPLOYEE <auth> field.
Bob learns Alice's public key and builds a certificate using his own
name and her key, getting it signed by some reputable commercial CA.
Now when it comes time to dispute prior art on Alice's patent(s), Bob
produces his certificate and claims that Alice had copied not only
his work but his private signature key.
For another example, Bob could give Alice read-write access to a
directory structure Bob intends to corrupt, blaming that corruption
on Alice.
To resolve this, some certificates should be signed by the <subject>
as well as by the <issuer>. An identity certificate is one such. At
Ellison, Frantz, Thomas [Page 27]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
this time we leave that option up to the builder of certificates, as
indicated by the DUAL-SIG option.
3.14 Secret Certificates
A concern was raised on the list about possible leaking of sensitive
information in the contents of a certificate.
Should it ever develop that a certificate needs to be issued whose
<auth> is itself private information, such <auth> fields can be
encrypted in a key known only by the intended verifier before being
returned to the subject. Presumably the subject knows the effect of
the certificate but anyone observing the certificate on the network
would be prevented from gaining knowledge of it.
Similarly, an entire certificate could be encrypted in a key known
only to the issuer, with the same effect.
Ellison, Frantz, Thomas [Page 28]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
4. Certificate Formats
We define a single certificate format, in binary, but rather than
pepper this document with pictures of binary structures, we define an
equivalent format in ISO 10646/UTF-8 (ASCII) and use that format in
the body of this text. In a separate file, we provide C programs for
converting between binary and UTF-8 formats. We take as a rule that
the thing signed is the binary thing transmitted, even if it is
expressed in UTF-8 format.
4.1 Certificate Fields
The following fields make up an SPKI certificate.
4.1.1 Subject
SUBJECT: <alg>,<hash>
The subject of a certificate is a keyholder and is indicated by the
hash of the subject's public key. By hash we mean a pair of values:
hash algorithm name and hash value. The actual key is assumed to be
in the verifier's possession although a given protocol might call for
transmitting that key during the same communication that carries the
certificate using it.
4.1.2 Subject-Cert
SUBJECT-CERT: <location>
The subject-cert field gives the location of the subject public key
and a self-signed validity certificate for that key. The <auth> of
that certificate can be anything -- e.g., a comment. If the private
key is ever compromised, then this self-signed certificate is revoked
or not renewed, depending on the keyholder's choice of validity
method.
Such a location might be a URL or domain name (for lookup in the DNS
database).
A self-signed validity certificate has no SUBJECT-CERT field.
A <location> is a text string.
Ellison, Frantz, Thomas [Page 29]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
4.1.3 Issuer
ISSUER: <alg>,<hash>
The issuer of a certificate is a keyholder and is indicated by the
hash of the issuer's public key.
4.1.4 Issuer-Cert
ISSUER-CERT: <location>
The issuer-cert field gives the location of the issuer public key and
any certificate(s) needed to establish the authority to do the
delegation represented by this certificate.
4.1.5 <auth>
As described in section 5, this class of field includes a large
number of options and carries the meat of a certificate. There are
<auth> fields for each kind of authorization or authority being
delegated as well as for establishing identity certification or
simply providing information.
An SPKI certificate is assumed to contain 0 or more <auth> fields,
but we expect most to contain only one.
4.1.6 <validity>
As described in section 6, this class of field includes options. A
certificate can have no <validity> field and be valid forever, have a
simple expiration date, or require periodic revalidation. That
latter can be achieved by having a certificate itself revalidated or
by having the certificate not show up on a CRL.
The "validity time" of a certificate is the time until it
expires or needs to be revalidated or needs a new CRL update,
whichever comes first. The latter two cases are periodic and
that period is the certificate's "validity period".
Ellison, Frantz, Thomas [Page 30]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
4.1.7 <signature>
There is one option for certificate signature. Every SPKI
certificate must be signed by the <issuer>. However, if the
certificate body contains the DUAL-SIG field, then the certificate
must also be signed by the <subject> in order to be valid.
4.2 Complex Policy Programs
A simple certificate is assumed to be part of a single thread of
authorizations -- a chain. There are policy programs which have been
considered [BFL] which would refer back to more than one certificate
and therefore not be part of a single chain.
The node which indicates which certificates to apply to which program
in order to acquire that program's <auth> need not be a certificate
itself. That is, there is no reason for it to be signed. All of its
integrity protection exists in the protection of the program which is
executed and of the individual certificates which are that program's
parameters. However, it may be useful to consider it a certificate
for the purpose of storage and display of certificate meshes
(chains).
A complex policy "certificate" would have more than one <issuer> and
would refer to a <program> rather than state an <auth>. The
parameter to such a program is a certificate, granting in effect a
partial authority. That is, the program is used to combine the
effects of multiple authorizations.
For that purpose, let us define:
PP-PARAM: <n>,<cert hash>,<cert location>
giving Policy Program Parameter number n, and
PP-PROG: <program hash>,<program location>
where <program location> gives the node or TCP port (or other
location) at which one submits the group of certs (ie., this block)
in order to get a specific permission or, more likely, a CRCert for
that permission.
Ellison, Frantz, Thomas [Page 31]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
4.3 Boundary lines BEGIN and END
Any multiple-line object, such as a certificate body or a signature,
is bounded by the lines:
BEGIN: <(possibly empty) comment or name>
and
END: <(possibly empty) comment or name>
Name matching is not performed but one can use the same name or
comment on corresponding BEGIN and END lines in order to make a set
of certificate bodies more readable to a human examining it. There
is no occasion to nest BEGIN-END pairs.
The hash of an object includes the BEGIN and END and their comments.
4.4 Binary Format
Each tag is assigned a binary value. For now we use single unsigned
bytes but reserve bytes in the range 128-255 to indicate that the
value is extended by one more unsigned byte. It is unlikely that
there would be a need for more than 2^15 different tags -- especially
given the ability to define <auth> tags in UTF-8.
The table of tag definitions is given in section 9 and is left
incomplete at this point, until the list reaches consensus on which
<auth> fields are viable enough to be given binary encodings.
4.5 Date Format
Dates in binary are assumed to be in the form of a 32-bit unsigned
integer, giving seconds since 1970-01-01.00:00:00 UTC.
In UTF-8 (ASCII) the date and time can be expressed in the form:
YYYY-MM-DD.HH:MM:SS
assumed to be UTC, with lower significance time fields optional and
taken to be 0 if missing. (We assume that this standard will be
supplanted by something better prior to the year 2106.)
Ellison, Frantz, Thomas [Page 32]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
5. <auth> Field Examples
The <auth> fields listed here are not meant to be an exhaustive list
of all possible <auth>s. Such is not possible. The final arbiter of
what needs to be an <auth> and what parameters a particular <auth>
needs is the designer of the code which verifies a certificate, e.g.,
to grant access. Listed here are <auth> fields we know to be useful.
For cases we have not anticipated, there is a field "AUTH:" to handle
arbitrary new <auth> fields. Not all of the <auth> fields described
below have binary tag formats, in which case "AUTH:" format needs to
be used (or the binary tag list needs to be updated).
When one grants some authority, it might be desired also to grant the
permission to delegate that authority to others. Each <auth> is
assumed to have a modifier, "MAY-DELEGATE:", specifying the
<subject>'s permission to delegate.
5.1 Delegation
MAY-DELEGATE: <deleg>
MAY-DELEGATE is a modifier of any <auth>, specifying whether the
<subject> has permission to delegate that <auth> to other keys.
<deleg> is an integer in the range [0,254], giving the depth of
delegation permitted, or the value "infinity" (represented in ASCII
as "*" and in binary as 255).
Verification of a certificate chain requires the <deleg> of a
<subject>'s cert to be less than the <deleg> of the <issuer>'s cert
(where (*)<(*) and ((*)-1)=(*)).
If there is no MAY-DELEGATE modifier, then <deleg> is assumed to be 0
and the cert in question does not grant permission to delegate.
5.2 Internet Access Control
FTP: <hostname>, <username>
TELNET: <hostname>, <username>
USER: <hostname>, <username>
These <auth> fields give permission to perform the indicated protocol
on the machine <hostname> as user <username>, and maybe permission to
Ellison, Frantz, Thomas [Page 33]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
delegate that authority (or a subset of it) to others. The USER
<auth> statement stands for *: -- ie., all protocols.
5.3 Public Key Protected File System
PKPFS://<hostname>/<path> (<access>)
PKPFS://<hostname>/<path>/ (<access>)
refers to a hypothetical distributed file system whose access is
controlled by public key challenge/response.
If <path> ends in "/" (as in the second example), access is to an
entire subtree. Otherwise, it is to an indicated file (or set of
files via "*").
<access> is a set of letters:
R: for read
W: for (over-)write
A: for add to directory (or append to file)
D: for delete
Such a file system has not been constructed and may never be, but
this example is included to illustrate the potential of <auth> field
construction.
5.4 HTTP Access
HTTP://<hostname>/<path>
HTTP://<hostname>/<path>/
Following the pattern for PKPFS, but using a real protocol, we can
permit read access to web pages -- either a selected set of pages
(via "*") or an entire directory subtree.
5.5 New <auth> fields
AUTH: <auth-tag>,<N>,<parameters>
The final arbiter of what needs to be an <auth> and what parameters a
particular <auth> needs is the designer of the code which verifies a
certificate. For those who want to define new <auth> fields without
waiting for the assignment of tag numbers, we provide the AUTH: tag.
Ellison, Frantz, Thomas [Page 34]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
<auth-tag> is a text version of the new tag. There is no attempt to
make <auth-tag> globally unique. It is assumed to be defined and
unique only among certificates from a given <issuer>.
<N> is the number of parameters to follow.
<parameters> are N (text or byte) string parameters.
The verifying application is responsible for establishing formats.
There is no desperate need for different applications to use the same
format so there is no need to standardize <auth> definitions before
they are first implemented. In Internet tradition as new formats are
invented for a particular purpose, they can be published and, if
found to meet the needs of others, generally adopted. Once they are
adopted by enough applications, they can be codified in the form of a
binary format with its own tag definition.
5.6 SET Certificates
The SET (Secure Electronic Transactions) standard work has come up
with authorization and identity certificates using X.509 format. The
corresponding SPKI formats (for CRCerts of SET certificates) might
have <auth> lines:
SET-BLIND: <nonce>,<PAN hash>
identifying card holders, where <nonce> is effectively a random
value used as a key in keyed-MD5 for generating <PAN hash> from
the card holder's Primary Account Number;
SET-MER: <brand>,<merchantID>
identifying merchants, where <brand> is the name of a credit
card brand and <merchantID> is the ID for that merchant assigned
by that card association;
SET-CCA: <brand>
identifying cardholder certification authorities;
SET-MCA: <brand>
identifying merchant certification authorities;
SET-PGWY: <brand>
identifying an approved payment gateway;
SET-PCA: <brand>
identifying a payment gateway certification authority;
Ellison, Frantz, Thomas [Page 35]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
SET-GCA: <brand>
identifying a regional certification authority (for approving
CCA, MCA or PCA);
SET-BCA: <brand>
identifying a brand certification authority (for approving GCA);
SET-ROOT:
identifying the SET root authority.
5.7 Identity Certificates
A traditional identity certificate doesn't fit the SPKI model. It
lacks an explicit transfer of authority. One can assume that it is
intended to imply that all the authority of the indicated person is
to transfer over to the subject key, but that is both unstated in the
certificate (and in many CA policy statements) and a very broad
delegation of authority. However, some policy definitions will
require identity certification. The identity certificate <auth>
forms listed below cover the most frequently cited cases.
5.7.1 Authority flow from Name to Key
EMPLOYEE: <name>, <company>, <division etc.>
implies that the subject is an employee named <name> of <company>
(with optional further specification by division of the company).
POSTAL-PATRON: <name>, <address>
signed by the post office, implies that the indicated person has
demonstrated to the post office the possession and use of the
associated private key (possibly through a mail exchange).
TELEPHONE-CUSTOMER: <name>,<phone number>
signed by the phone company, implies that the indicated person has
demonstrated to the telephone company the possession and use of the
associated private key (possibly through a message exchange via
modem).
Other delegations of authority should be structured similarly, if any
others are of interest. These are the ones the literature most often
Ellison, Frantz, Thomas [Page 36]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
cites. In all of these cases, a COMMENT field can be included to
give an explanation of how the association between key and person was
established.
5.7.2 SDSI Name
NAME: <name>
implies that the issuer uses the name <name> for the subject
keyholder (i.e., for the subject key), according to SDSI usage. That
is, <name> is strictly local for the issuer [SDSI]. The <name> can
be a single name or a SDSI name chain.
For example, (carl ron butler) means that whoever the issuer knows as
"carl" has a local name "ron" for some entity which has a local name
"butler" for the entity with which the issuer associates the
<subject> key.
If this certificate is self-signed (if <subject> = <issuer>) then it
can be taken to mean "I go by the name <name>" or "I prefer to be
called <name>".
(See also MEMBER and NON-MEMBER in Section 5.10.2 for SDSI group
definitions.)
5.7.3 PGP-like Reference
KNOWN-TO-ME-AS: <name>,<how>
is the commonly assumed meaning of a PGP key signature and implies
that the subject principal (ie., key holder) is known to the issuer
under the (presumably global) name <name>. The optional <how> field
indicates the degree to which key ownership has been verified, for
example:
signed challenge in person
key fingerprint
net contact
ranging from having signed a random challenge while the issuer
watched the process to the issuer's never having met the person
except over the net.
Ellison, Frantz, Thomas [Page 37]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
5.7.4 Location Information
LOCATION: <text string>
RESPONSIBLE-PARTY: <name>
For some purposes, such as interpretation of an audit log, it is
necessary to locate a keyholder (device or person) in physical space.
This binding of information to the keyholder (therefore, to the key)
is provided by a security office, a physical plant office, inventory
control office, etc., which needs to issue and sign the LOCATION or
RESPONSIBLE-PARTY certificate.
If there arise programmatic interpretations of such location fields,
then there might be a need to specialize them by choice of tag name,
but as long as these fields are for human consumption only, all
specialization (e.g., person's name, room number, license plate of
vehicle, ...) can be indicated in the free form text parameter.
5.7.5 Informational Self-binding
MAILTO: <e-mail address>
lists an address at which the keyholder can receive e-mail. This
transfers authority from key to e-mail address, not the other way
around.
These certificates should be signed by the subject key -- that is,
the issuer and subject should be the same. (See section 3.2.2)
5.7.6 Dating Service Bindings
There is some information which might be certified for a fee by a
commercial on-line dating service:
MARITAL-STATUS: <status>
BIRTH-YEAR: <year>
HEIGHT: <height>
WEIGHT: <weight>
PICTURE: <hash of image file>,<location of image file>
Ellison, Frantz, Thomas [Page 38]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
5.8 Authority to spend money
SPENDING-AUTHORITY: <amount>,<kind of purchase>
indicates that the subject has authority to authorize spending up to
<amount> per purchase order. The purchasing authority can be limited
to a particular kind of purchase, optionally, but that optional field
will have to be interpreted by humans at this point. No guidance is
given for its contents.
If <deleg> (cf., 5.1) is greater than 0, the subject is authorized to
delegate SPENDING-AUTHORITY to others under the rule that the
delegated <deleg> be less than the subject's and that the delegated
<amount> be less than or equal to the subject's while the <kind of
purchase> (a text field) is the same or more limited. Interpretation
of that last might require human intervention. (If human
intervention is required in the interpretation of a SPENDING-
AUTHORITY certificate chain, it might be prudent always to generate a
CRCert of the result.)
5.9 Comments to human readers
COMMENT: <text>
These fields are completely unconstrained and included by the
<issuer> for human interpretation.
5.10 Group membership
5.10.1 Authorization groups
DELEGATE-ALL:
A group is an entity to which authority is delegated in order for
that authority to be delegated to all group members. If authority is
delegated strictly via SPKI certificates, the group declares that
<subject> is a member by issuing a:
(<group key>,<subject>,"DELEGATE-ALL")
certificate.
Ellison, Frantz, Thomas [Page 39]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
DELEGATE-ALL is a wild card <auth> field which stands for any and all
<auth> fields which the <issuer> has permission to delegate -- each
with <deleg> one less than that in the <issuer>'s cert. (See 5.1 for
the definition of <deleg>.)
This <auth> construct is especially for passing along the rights of a
group of users to the members of the group but it can also be used by
an individual user to delegate all if his or her own authority to a
temporary key for a limited period of time.
If the DELEGATE-ALL certificate includes a MAY-DELEGATE field, then
the effective <deleg> of that certificate for a given <auth> is the
minimum of the given <deleg> and one less than that of the <issuer>'s
<auth> certificate.
5.10.2 SDSI groups
MEMBER: <group name>
NON-MEMBER: <group name>
The subject key (ie., principal) is positively confirmed to be a
member (or non-member, respectively) of the indicated SDSI group.
The group name is in the name space of the certificate issuer (as in
SDSI).
5.11 Other Certificate
CERTIFICATE: <hash of certificate body>
This <auth> means that the <issuer> has validated the indicated
certificate to its own satisfaction. No clear use of this construct
is envisioned at this time, but it is included here as an example of
the kind of <auth> field which can be defined.
5.12 Certificate for Blind Signatures
There is sometimes a desire to create a blind signature on a key.
Current methods call for a blinded quantity to be given to the
prospective issuer which signs it and gives the signed quantity back
to the subject. The subject unblinds the quantity, yielding a signed
quantity which the issuer has never seen in the clear.
Ellison, Frantz, Thomas [Page 40]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
If this blinded quantity were an SPKI certificate, the issuer would
have no control over the <auth> or <validity> fields.
One possible solution to this problem employs the <auth> field
modifier
INDIRECT-SUBJECT:
In the following certificate:
BEGIN:
SUBJECT: K1
(...)
INDIRECT-SUBJECT:
<auth>
<validity>
END:
the INDIRECT-SUBJECT indicates that the combination of this
certificate and a key, K2, signed by K1 is taken to be functionally
equivalent to the certificate:
BEGIN:
SUBJECT: K2
(...)
<auth>
<validity>
END:
Ellison, Frantz, Thomas [Page 41]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
6. <validity> Fields
As described in section 3.12, a certificate has some validity period.
Its use will be limited by the validity period of any certificates on
which it depends but it can have its own validity limitations.
If there is no validity specification, a certificate is assumed to be
valid forever.
6.1 Expiration
EXPIRES: <date>
gives a firm expiration date for the certificate, before which a
replacement must be issued with a new expiration date.
RENEW-LOCATION: <location>
This is the location (URL, SMTP name, DNS name or TCP port) to get
the certificate's VALID-TO date changed, get a new CRL (update) or
get ECR revalidation.
6.2 Re-validation
VALID-TO: <date>
gives a temporary validity date and time. The certificate needs to
be re-issued with an updated validity date and time if the indicated
time has passed. (This is equivalent to EXPIRES and is included as a
separate item in case the issuer has a special procedure which must
be followed to reissue a certificate on the EXPIRES date (perhaps
involving payment of a fee).)
6.3 CRL
CRL: <duration>
where <duration> gives the lifetime of a CRL in seconds.
((Format of the CRL itself is TBD, but should probably involve the
ability to issue incremental CRL changes, on the assumption that a
CRL can grow very large and that a process which verifies validity by
Ellison, Frantz, Thomas [Page 42]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
CRL will therefore maintain a copy of the CRL and want to receive
only updates.))
6.4 Validity by Chained Hash
[ECR] gives a mechanism using chained hash values rather than public
key operations to indicate continued validity or revocation of a
certificate or CRL. (This method may be covered by one or more
patents.)
When applied to a certificate, one might have:
ECR-PARAMS: <date>,<duration>,<F>,<N>,<R>,<V>
where:
<date>: is the start date and time (date of issue) -- T;
<duration>: is the number of seconds between revalidations -- S;
<F>: is the name of the hash algorithm used;
<N>: is the number of hashes of the original seed (so that the
certificate can be revalidated until time T+(S*N));
<R>: is the hash value whose pre-image is to be returned if the
certificate has been revoked; and
<V>: is the N'th hash of the original seed.
If a certificate is still valid, the on-line validation service will
return the ((X-T)/S)'th pre-image of V, where X is the current time.
That hash value can be bundled with a certificate without needing to
be signed and provided as proof of current validity.
6.5 Session modifier
GOOD-ONLY-FOR-SESSION: <session ID>
This modifier of a certificate limits its validity to a particular
session (e.g., a TELNET connection or HTTP shopping session).
<session ID> is a text string.
Ellison, Frantz, Thomas [Page 43]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
7. <signature> Field and Key Definitions
7.1 Signature Format
The signature on a certificate (or, optionally, anything else) has
the format:
SIGNATURE: <hash alg>,<PK alg>,<sig value>,<body hash>
where:
<hash alg> is the name of the algorithm used to compute the hash
being signed;
<PK alg> is the name of the public key algorithm used to compute the
signature, including specification of any padding or internal
formatting;
<sig value> is the value of the signature; and
<body hash> is an optional field indicating the object being signed
by giving its hash. If this field is missing, the SIGNATURE is
taken to apply to the preceding BEGIN-END block.
7.2 Dual Signature Requirement
DUAL-SIG:
This line inside a certificate body means that the certificate is not
valid unless the <subject> has also signed it. Anticipated primarily
for identity certificates, this line makes explicit the good CA
practice of having the customer sign the subject key and accept the
issuance of the given certificate.
7.3 Key Format
A public key is described as:
KEY: <alg>, <fields as required by alg>
For example, the two common ones (for signature keys) are:
Ellison, Frantz, Thomas [Page 44]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
KEY: RSA,<e>,<N>
KEY: DSA,<y>,<q>,<p>
Ellison, Frantz, Thomas [Page 45]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
8. Examples
(to be given)
Ellison, Frantz, Thomas [Page 46]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
9. Binary Format
9.1 Tag definitions
This table of definitions is subject to extension as <auth> fields
become widely accepted.
9.1.1 Non-auth fields
The following are all the non-auth fields given in this document.
0: END
1: BEGIN
2: SUBJECT
3: SUBJECT-CERT
4: ISSUER
5: ISSUER-CERT
6: EXPIRES
7: RENEW-LOCATION
8: VALID-TO
9: CRL
10: ECR-PARAMS
11: GOOD-ONLY-FOR-SESSION
12: SIGNATURE
13: DUAL-SIG
14: KEY
9.1.2 Auth fields
The following are some of the <auth> fields given in this document.
Only those which we believe to be truly useful are assigned tags.
The others may use the AUTH: construct (or, may later be assigned tag
numbers).
32: MAY-DELEGATE
33: AUTH
34: FTP
35: TELNET
36: HTTP
37: EMPLOYEE
38: NAME
39: KNOWN-TO-ME-AS
Ellison, Frantz, Thomas [Page 47]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
40: LOCATION
41: RESPONSIBLE-PARTY
42: MAILTO
43: SPENDING-AUTHORITY
44: COMMENT
45: DELEGATE-ALL
46: MEMBER
47: NON-MEMBER
48: INDIRECT-SUBJECT
49: USER
9.2 Integer format
There are 4 integer sizes: <byte>, <short>, <long> and <byte-string>.
A <byte> is expressed as just the byte.
A <short> is encoded as two bytes, higher order byte first.
A <long> is encoded as four bytes, most significant byte first.
A <byte-string> is a <short> count followed by that number of bytes
of the string, most significant byte first.
The indication of size of integer is to be built in to the field
definition so that no bytes are used to indicate that size.
9.3 Date format
A date is a <long>, giving the number of seconds since
1970-01-01.00:00:00 UTC.
9.4 String format
A string is a <short> byte count followed by the bytes of the UTF-8
string. (Text strings and byte strings are intentionally encoded the
same way.)
Ellison, Frantz, Thomas [Page 48]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
9.5 Algorithm definitions
The standard algorithms are:
0: ALG 1: MD5 2: SHA-1 3: RSA 4: DSA
with room for expansion as new algorithms gain popularity.
The ALG option is followed by a text string naming an algorithm, for
use when this list of defined algorithms has not yet been updated.
9.6 Hash fields
A <hash> field is a byte string.
Ellison, Frantz, Thomas [Page 49]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
References
[BFL] Matt Blaze, Joan Feigenbaum and Jack Lacy, "Distributed Trust
Management", Proceedings 1996 IEEE Symposium on Security and Privacy.
[DNSSEC] Donald Eastlake and Charles Kaufman, "Domain Name System
Security Extensions", (working draft of the DNSSEC Working Group).
[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.
[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)
[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", working draft,
06/12/1996.
Ellison, Frantz, Thomas [Page 50]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
[RFC1321] The MD5 Message-Digest Algorithm, R. Rivest, April 16 1992.
[SDSI] Ron Rivest and Butler Lampson, "SDSI - A Simple Distributed
Security Infrastructure [SDSI]",
http://theory.lcs.mit.edu/~rivest/...
[SRC-070] Abadi, Burrows, Lampson and Plotkin, "A Calculus for Access
Control in Distributed Systems", DEC SRC-070, revised August 28,
1991.
Ellison, Frantz, Thomas [Page 51]
INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997
Authors' Addresses
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
Brian Thomas
Southwestern Bell
One Bell Center, Room 23Q1
St. Louis MO 63101 USA
Telephone: +1 314-235-3141
+1 314-331-2755(fax)
EMail: bt0008@entropy.sbc.com
Bill Frantz
Periwinkle
16345 Englewood Ave.
Los Gatos, CA 95032
Telephone: +1 408-356-8506
Email: frantz@netcom.com
Expiration and File Name
This draft expires 22 September 1997.
Its file name is draft-ietf-spki-cert-structure-00.txt
Ellison, Frantz, Thomas [Page 52]