Simple Public Key Certificate Carl M. Ellison
INTERNET-DRAFT CyberCash, Inc.
Expires: 30 September 97
Bill Frantz
Periwinkle
Brian M. Thomas
Southwestern Bell
25 March 1997
Simple Public Key Certificate
------ ------ --- -----------
Status of This Document
This document supersedes the draft filed under the name draft-ietf-
spki-cert-structure-00.txt and reflects changes in the structure to
prepare the way for merging the SPKI certificate structure of the
previous draft with the SDSI proposal of Rivest and Lampson. The
primary change is the use of S-expression format for data objects
such as certificate bodies.
A section giving the BNF of all data objects is given so this draft
is more complete than the previous one. It has also been simplified
in a number of places. The draft ends with a list of open questions
for group discussion.
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
Ellison, Frantz, Thomas [Page 1]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Ellison, Frantz, Thomas [Page 2]
INTERNET-DRAFT Simple Public Key Certificate 25 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" has been 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.) This process is designed to transfer a relationship between
two entities from the physical world into the digital world.
The Internet itself changed the world from the one in which identity
certificates were considered necessary. As Internet use increases,
we increasingly interact with people or companies with whom we have
no relationship in the physical world. A transfer of relationship
from the physical world to the digital world is meaningless in such
cases. Instead, we need to establish relationships directly in the
digital world through an instrument which assigns attributes
(authority, permission, ...) to the digital principal. We call that
an "authorization certificate".
SPKI certificates were designed to perform that function by directly
specifying the <auth,key> binding which is of interest in the digital
world.
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], KeyKOS [HARDY]) 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 25 Mar 1997
Table of Contents
Status of This Document....................................1
Abstract...................................................3
Acknowledgments............................................3
Table of Contents..........................................4
1. Overview of Contents....................................6
2. Scope Of This Effort....................................7
2.1 Charter of the SPKI group..............................7
2.2 Areas Covered And Not Covered..........................7
2.2.1 Key and certificate storage..........................7
2.2.2 Protocols to use public key authentication...........8
2.3 Other Certificate Formats..............................8
2.4 Goals of this effort...................................9
2.5 SPKI Certificates vs. Capabilities.....................9
2.6 Chosen standard format.................................9
3. Assumptions, Definitions and Design Issues.............10
3.1 Background............................................10
3.2 Binding of key to principal...........................11
3.2.1 Protection of Private Keys..........................11
3.2.2 Definition of KEYHOLDER.............................12
3.3 Certificate Structure.................................13
3.3.1 5-tuple Reduction...................................13
3.3.2 Authority Loops.....................................14
3.3.3 Certificate Result Certificates.....................14
3.4 Policy Structures.....................................15
3.4.1 Equality of <auth>..................................16
3.4.2 Partial ordering of <auth>s.........................16
3.4.3 General <auth> fields...............................16
3.5 Certifying Identity with SPKI Certificates............16
3.6 Certificate validity periods..........................17
3.7 Unwanted Attributions.................................19
3.8 Secret Certificates...................................19
3.9 Blind Signatures......................................20
4. Data Object Formats....................................21
4.1 BNF of SPKI Objects...................................21
4.1.1 Version.............................................24
4.1.2 Issuer..............................................24
4.1.3 Issuer-cert-loc.....................................24
4.1.4 Subject.............................................24
4.1.5 Subject-info-loc....................................25
4.1.6 May-delegate........................................25
4.1.7 Auth................................................25
4.1.7.1 Auth field reduction rules........................25
Ellison, Frantz, Thomas [Page 4]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
4.1.7.2 Auth global uniqueness............................26
4.1.8 Comment.............................................26
4.1.9 Not-after, Not-before...............................26
4.1.10 Online.............................................26
4.1.11 Signature..........................................27
4.1.12 Bundle.............................................27
4.1.13 <pub-key>..........................................27
4.1.14 Hash...............................................27
4.1.15 <secret-sig-key>...................................28
4.1.16 Fully-qualified-name...............................28
4.1.17 Ref................................................28
4.1.18 Date...............................................29
4.2 Primitives............................................29
4.2.1 byte-string.........................................29
4.2.1.1 token.............................................29
4.2.1.2 quoted string.....................................29
4.2.1.3 hex string........................................29
4.2.1.4 base64 string.....................................30
4.2.1.5 literal binary string.............................30
4.2.1.6 concatenation of strings..........................30
4.2.2 Display information.................................30
4.2.3 List counts.........................................31
4.3 Binary (canonical) form...............................31
4.3.1 Byte strings........................................31
4.3.2 List counts.........................................31
4.3.3 blanks..............................................31
5. <auth> Field Examples..................................32
5.1 Member-of-issuer......................................32
5.2 Name..................................................32
5.3 Member................................................32
5.4 FTP...................................................33
5.5 HTTP..................................................33
5.6 TELNET................................................33
5.7 Public Key Protected File System......................33
5.8 Dating Service Bindings...............................34
5.9 Authority to spend money..............................34
Issues....................................................35
References................................................37
Authors' Addresses........................................39
Expiration and File Name..................................39
Ellison, Frantz, Thomas [Page 5]
INTERNET-DRAFT Simple Public Key Certificate 25 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 SPKI data object formats -- listing the fields in
a certificate and giving encoding details.
Section 5 describes predefined 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.
The Issues section gives a list of open questions to be resolved by
the SPKI working group.
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 6]
INTERNET-DRAFT Simple Public Key Certificate 25 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.
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 create a new
Ellison, Frantz, Thomas [Page 7]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
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.
SDSI demonstrated certificate servers for individuals to run on their
own net-connected workstations, in response to the fact that more and
more individuals remain connected to the network permanently.
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
encourage other developers to actively enter this area of design,
aided by SPKI certificates as a tool.
2.3 Other Certificate Formats
We are aware of a number of actual and proposed kinds of signed
records 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
5. Signed PICS labels (from the W3C DSig effort)
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
Ellison, Frantz, Thomas [Page 8]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
concerned.
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 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
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.6 Chosen standard format
In this draft, the standard format adopted is that developed by SDSI,
modified slightly. Data objects are defined as S-expressions --
lists in which the first element is a token defining the data object.
Ellison, Frantz, Thomas [Page 9]
INTERNET-DRAFT Simple Public Key Certificate 25 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 Background
In the words of Butler Lampson, a public signature key "speaks for"
its owner: a person or entity we call the "keyholder". It is
primarily through such public key "speech" that one achieves security
on the inherently anonymous and spoofable Internet.
There is a long standing effort to bind public keys to the "true
names" of their keyholders, in an attempt to identify the keyholder
and to permit the transfer of permissions or other attributes from
the physical world in which the keyholder lives into the digital
world. This effort has produced identity certificates, such as
X.509, giving <name,key> bindings which needed to be combined with
certificates or ACL entries giving <auth,name>, to yield the
relationship <auth,key> which a computer needs to verify public-key
driven access attempts. {<auth> here stands for authorization,
permission, etc.}
The Internet has changed the world from the one in which identity
certificates were originally seen to be necessary. In the new world
of the global Internet the entities which communicate are often not
known to each other in the physical world. This trend is likely to
increase as time goes on. Therefore a mechanism which transfers
attributes from the physical world to the digital world is
inappropriate.
We also observed that <key> is a perfectly adequate name for a
keyholder, at least as far as a computer is concerned. We therefore
set about declaring a certificate which would communicate <auth,key>
directly, leaving names out of the process except in the case where
the name is the item of interest (e.g., for secure e-mail).
Ellison, Frantz, Thomas [Page 10]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
3.2 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.
3.2.1 Protection of Private Keys
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 or SmartCard 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 (that is, 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
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.
Ellison, Frantz, Thomas [Page 11]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
Note: We have specifically included the possibility for a holder
of authority to delegate that authority without appeal to some
certification authority, 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 authentication and authorization.
3.2.2 Definition of 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.
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.
Ellison, Frantz, Thomas [Page 12]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
3.3 Certificate Structure
An SPKI certificate body has five groups of fields:
ISSUER: the public key of the issuing party or something reducible to
that public key, both as a means for verifying the certificate
signature and as a name for the issuing principal.
SUBJECT: the object receiving authority via this certificate or
something reducible to that object (usually a key or the hash of
a key or a document).
MODIFIERS: modifiers on the certificate. At present the only one
defined is "May-delegate:" -- the permission to delegate the
authority presented in the certificate (or part of it) to some
other Subject.
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.
A certificate is signed by the issuer and, optionally, by the
subject. The dual signature is required for authorizations which
also imply responsibilities. The issuer is granting an
authorization, but the subject is accepting responsibility. Each of
those actions requires a signature.
Section 7 gives details about signature blocks.
3.3.1 5-tuple Reduction
The authorization statement in a valid certificate can be represented
by five quantities:
(I,S,D,A,V)
A set of certificates can be reduced as follows:
(I1,S1,D1,A1,V1) + (I2,S2,D2,A2,V2)
becomes
Ellison, Frantz, Thomas [Page 13]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
(I1,S2,D2,A,V)
if S1=I2 (meaning that they are or resolve to the same public key)
and D1 > D2 (if delegation is integer) or D1 >= D2 (if delegation is
boolean)
and A = intersection(A1,A2)
and V = intersection(V1,V2)
3.3.2 Authority Loops
By 5-tuple reduction, some chains of certificates will be reduced to
the form:
(Self,X,D,A,V)
where "Self" represents the computer doing the verification, granting
access, etc. Such a 5-tuple says "Self says that X has authority
(D,A) for validity period (or conditions) V". In other words, it
tells Self what it can trust about X.
Any certificate chain not reducing to a 5-tuple with Self as issuer
isn't relevant to decisions by Self.
Therefore, any certificate chain which is to be used by Self to do
trust management must have Self as a root. Since Self is doing this
chain reduction, that makes all useful authorization certificate
chains loops.
3.3.3 Certificate Result Certificates
If one has reduced a chain of certificate bodies down to the form:
(Self,X,D,A,V)
one can sign that generated body, using a private key of Self,
producing an SPKI certificate. Such a certificate is the result of
5-tuple reduction (and possibly PolicyMaker execution) over one or
more certificates (which could be of various formats, including SPKI,
X.509, DNSSEC, ...). This certificate result certificate, CRC, could
then be given back to the caller (protocol permitting) for that
caller to use throughout interval V. Such a certificate should
reduce transmission and verification time. The signature used by
Self could even employ a secret-key algorithm, on the assumption that
the issuer and verifier are the same entity. Alternatively, one
Ellison, Frantz, Thomas [Page 14]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
could use a public-key-signed CRC to enable a trusted server to
translate certificate formats from something difficult to deal with
(such as X.509) into SPKI.
3.4 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.
PolicyMaker is likely to be used along with SPKI certificates in
three ways.
1) It is believed possible to use the PolicyMaker language to
implement the 5-tuple reduction described in the previous section.
The code has not been written as of the time of this draft, but at
this point it looks possible.
2) The default reduction rule is an operation on two certificate
bodies yielding a third. For some policies, there are more than
two input bodies and therefore the reduction code needs to be more
general than the simple rules given in the section above.
3) For some kinds of trust management, it will be necessary to
translate <auth> fields. That is, the simple rule
A=intersection(A1,A2)
makes it impossible for A to be greater than either A1 or A2. For
example, if company policy is that a purchase order is good only
if signed by two vice presidents, A1a might be "signed by VP #1"
and A1b might be "signed by VP #2", while A=A2 might be "purchase
order is good". Neither of the VPs has the authority to make a
purchase order good by himself or herself. Therefore, A > A1a and
A > A1b.
The first case is a matter of coding convenience. The others are
cases of logic of trust management.
There must be machinery in the verifying engine which reduces
certificate bodies. For everything but <auth> fields, this is
straight-forward. Since every verifier of certificates is permitted
to define custom <auth> fields, with custom semantics, the simple
reduction rules given above might not suffice and full PolicyMaker
programs might be needed.
Ellison, Frantz, Thomas [Page 15]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
Three forms of <auth> processing during 5-tuple reduction are
envisioned for the engine running in the verifier:
3.4.1 Equality of <auth>
This simplest of reduction operations applies when <auth> fields are
equal. No logic is required to supplement the reduction operation.
3.4.2 Partial ordering of <auth>s
If the definer of the <auth> field specifies rules for partial
ordering of those fields, the engine which reduces them can choose
the lesser of A1 and A2 and choose that as A -- to perform the normal
reduction indicated above.
3.4.3 General <auth> fields
In the most general case, the definer of the <auth> field must
provide a program which reduces these fields. That program is not
limited to taking two certificate bodies in and producing one on
output, as is true for the default rule. It can take one or more
certificate bodies and produce one or more outputs (although a single
output is probably sufficient for our purposes).
3.5 Certifying Identity with SPKI Certificates
It is possible to certify identity with an SPKI certificate. We
support the SDSI naming mechanism, since we recognize that all names
are local to some name-space -- even when that name-space desires to
be treated as global.
[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
Ellison, Frantz, Thomas [Page 16]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
spaces. That is, two people, Alice and Bob, may each have a friend
they call Carol. To each of them, the name (ref: carol) is used. If
Ted knows both Alice and Bob, then Ted might have occasion to speak
with each of them about Carol. Not necessarily having met Alice's or
Bob's Carol, Ted uses the names (FQN: K-ted alice carol) and (FQN: K-
ted bob 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,K1,D1,"(Name: carol)",V1)
(K-bob,K2,D2,"(Name: carol)",V2)
If K1 = K2, then Alice and Bob both use the name Carol to refer to
the same person. 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. After that period, Ted may have to get new certificates
from Alice and Bob to determine if they still refer to the same
person by the name Carol. Of course, this is an academic exercise
since the names by which Alice and Bob know the keyholder of K1 is
probably of limited importance.
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.
SDSI names are defined with the <auth> fields: Name: and Member:
described later in this document.
3.6 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
Ellison, Frantz, Thomas [Page 17]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
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.
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
Ellison, Frantz, Thomas [Page 18]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
validity period is left up to the issuer of the certificate.
The closest one can get to zero-length validity fields is an on-line
check with random challenge response, so that it can not be replayed.
Such a check can be considered valid only for that one transaction.
3.7 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. It
is an open issue whether we should require all certificates with keys
for <subject>s to be signed by both <issuer> and <subject>.
3.8 Secret Certificates
Some certificates need to be kept secret (e.g., a certificate binding
a name to a symmetric-algorithm signature key). Such certificates
can be encrypted in a key known only to the intended verifier. In
some cases, it is that verifier who issued the certificate and in
that case it can be kept in protected storage at the verifier and
never given out.
Ellison, Frantz, Thomas [Page 19]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
3.9 Blind Signatures
The issue of blind signatures was raised on the list. As can be seen
from the format of the Signature: object, normal blinding (e.g., of
RSA by pre- and post- multiplication of a signature value) can be
applied. It is an open issue whether blinding of other algorithms
can be accommodated as easily.
Ellison, Frantz, Thomas [Page 20]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
4. Data Object Formats
Borrowing heavily from the SDSI work, we define a certificate format
using S-expressions. An S-expression is a list whose first item is a
token giving the name of the object (or identifying some program to
run) while the remaining items are parameters. These parameters can
be positional and merely tokens or they can be lists whose first
token is the name of the parameter. In most cases we assume
parameters are named and leave positional definitions as an option
for those who create their own <auth> expressions.
There is a set of rules for converting from S-expression to a minimal
size binary format. That is the form which is fed to a hash function
when signing an object. It is also available as a binary format for
transmission into a device with small memory or slow interface (such
as a SmartCard). Those rules are given below, in section 4.3.
It is our intention to provide C programs for converting between
binary and S-expression formats. We take as a rule that the thing
signed is the binary of the thing transmitted, even if it is
transmitted in S-expression format. That is, the transmitted object
specifies order and content of parameters. The binary conversion
provides space-saving and canonicalization.
4.1 BNF of SPKI Objects
The following defines an SPKI certificate and related objects,
expressed here in pseudo-BNF -- with "*" meaning closure (0 or more
occurrences) and "?" meaning optional (0 or 1 occurrence). At the
top level (not used internally in any other object) are the following
three objects. Other objects (such as <pub-key>) might also occur at
a top level, to be hashed and referred to by hash.
<cert-body>:: "(" <T_cert> <version>? <issuer> <issuer-loc>?
<subject> <subject-loc>? <deleg> <auth> <comments> * <valid> ")" ;
<sig>:: "(" <T_sig> <principal> <sobj> <sig-val> ")" ;
<bundle>:: "(" <T_bundle> <s-expression> * ")" ;
Note that the fields in a <cert-body> don't need to be in the order
given by the BNF, because they are all self-identified, but we
recommend that they be given in that order, for human readability.
Defined below are the other elements of this BNF description.
Ellison, Frantz, Thomas [Page 21]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
<T_auth>:: "Auth:" | "A:" ;
<T_bundle>:: "Bundle:" ;
<T_cert>:: "Certificate:" | "C:" ;
<T_deleg>:: "D:" | "May-delegate:" ;
<T_fq_name>:: "FQN:" | "Fully-qualified-name:" ;
<T_hash>:: "H:" | "Hash:" ;
<T_iloc>:: "IL:" | "Issuer-cert-loc:" ;
<T_issuer>:: "Issuer:" | "I:" ;
<T_moi>:: "Member-of-issuer:" | "Moi:" ;
<T_notafter>:: "Not-after:" | "NA:" ;
<T_notbefore>:: "Not-before:" | NB:" ;
<T_pubkey>:: "K:" | "Public-key:" ;
<T_sig>:: "Signature:" | "Sig:" ;
<T_sloc>:: "SL:" | "Subject-info-loc:" ;
<T_subj>:: "Subject:" | "S:" ;
<URI>:: byte-string ;
<auth>:: "(" <T_auth> token <param> * ")" | <predefined-auths> ;
<comments>:: "(" "Comment:" byte-string * ")" ;
<deleg>:: "(" <T_deleg> <int> ")" ;
<fq-name>:: "(" <T_fq_name> <principal> <names> ")" ;
<hash-alg-name>:: "SHA1" | "MD5" | etc..... ;
<hash-of-key>:: <hash> ;
<hash-value>:: byte-string ;
<hash>:: "(" <T_hash> <hash-alg-name> <hash-value> <URI>? ")" ;
Ellison, Frantz, Thomas [Page 22]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
<host-name>:: byte-string ;
<int>:: byte-string ;
<issuer-loc>:: "(" <T_iloc> <URI> <param> * ")"
<issuer>:: "(" <T_issuer> <principal> ")" ;
<login-name>:: byte-string ;
<names>:: token | <names> token ;
<not-after>:: "(" <T_notafter> <date> ")" ;
<not-before>:: "(" <T_notbefore> <date> ")" ;
<obj>:: "(" "Object:" byte-string ")" ;
<online-test>:: "(" "Online:" <token> <URI> <param> * ")" ;
<param>:: byte-string | <s-expression> ;
<predefined-auths>:: "(" "FTP:" <host-name> <login-name> ")" | "("
"HTTP:" <URI> ")" | "(" "Name:" token ")" | "(" "Member:" token ")" |
"(" <T_moi> ")" | etc.... ;
<principal>:: <pub-key> | <hash-of-key> | <fq-name> ;
<pub-key>:: "(" <T_pubkey> <pub-sig-alg-and-key> ")" ;
<pub-sig-alg-and-key>:: "(" "RSA-SHA1-PKCS1:" "(" "E:" <int> ")" "("
"N:" <int> ")" ")" | "(" "RSA-SHA1-PKCS1:" <int> <int> ")" | etc....
;
<relative-name>:: "(" "Ref:" <names> ")" ;
<s-expression>:: "(" token <param> * ")" ;
<secret-sig-key>:: "(" "HMAC-SHA1:" <int> <int> ")" | etc.... ;
<sig-val>:: <param> ;
<sobj>:: <hash> | <obj> ;
<subj-obj>:: <principal> | <relative-name> | <hash> | <secret-sig-
key> ;
<subject-loc>:: "(" <T_sloc> <URI> <param> * ")" ;
Ellison, Frantz, Thomas [Page 23]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
<subject>:: "(" <T_subj> <subj-obj> ")" ;
<valid>:: <not-before>? <not-after>? <online-test>? ;
<version>:: "(" "Version:" <int> ")" ;
4.1.1 Version
If the version number is not specified, the version is 1.
4.1.2 Issuer
The issuer is a principal -- that is, a public key or something which
can be reduced to a public key -- because it is used to sign
certificates.
4.1.3 Issuer-cert-loc
The optional issuer certificate location field is for information
only. It gives a network address of a web page or server which can
return the issuer's certificate authorizing the current certificate.
4.1.4 Subject
The subject is a principal or something reducible to one, in the
normal case, but has been extended to also be a secret signature key
or the hash of an object.
1: principals include:
a: a public key
b: a fully qualified name
c: a hash of a public key
d: a relative name (anchored in the name-space of the issuer)
2: secret signature key -- like a principal, but there is no public
key which can be given out. The certificate which defines a
mapping to this secret key must itself be kept secret. This
certificate could define a name in the issuer's name-space as a
name for that key and the name could be used elsewhere.
Ellison, Frantz, Thomas [Page 24]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
3: hash of an object -- in case one wants to assign attributes to an
object. E.g., a purchase order could be "signed by VP # 103",
where that latter string is an <auth> field and the P.O. is the
Subject of the certificate.
4.1.5 Subject-info-loc
The subject information location is an optional field which provides
the location of a network resource where one can learn about the
Subject -- e.g., find the subject public key, find the subject's home
page, etc.
4.1.6 May-delegate
The May-delegate field is the only modifier defined on a certificate
so far. It is defined to take an integer parameter, currently, but
that may be changed to a boolean. This is an open issue.
4.1.7 Auth
The Auth field can be a pre-defined field, described in section 5, or
a custom field defined by a developer who is programming a use of
certificates. The custom definitions are of the form:
"(" <T_auth> token <param> * ")"
where the token is the developer's name for this <auth> and the
optional list of parameters are as defined by that developer. These
parameters can be position sensitive or can be S-expressions of the
form
"(" <parameter-name> <parameter-value> ")"
at the developer's discretion.
4.1.7.1 Auth field reduction rules
When a developer defines a new <auth> field, he or she must also
define how the new field is to be reduced. By default, two
Ellison, Frantz, Thomas [Page 25]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
certificates which have identical <auth> fields will reduce provided
the rest of the 5-tuple fields permit it. If strict equality is not
adequate, the developer can define partial ordering between <auth>
fields (e.g., sorting rules over different parameters). If partial
ordering relationships aren't adequate to reduce the intended <auth>
fields, then the developer can write a program to do that reduction
(as described elsewhere, under the heading of PolicyMaker).
4.1.7.2 Auth global uniqueness
If a developer desires to have a unique name for his or her <auth>
token in some global name-space, that name can have a true random
string appended, with length of string chosen according to the risk
of accidental duplication of name the developer is willing to
tolerate.
4.1.8 Comment
A comment field may contain any text or other strings the author
desires. These strings may have display instructions. The comment
is included in the signature of a certificate, but is not expected to
be read by any computer program.
4.1.9 Not-after, Not-before
The not-before and not-after dates are normal validity dates for a
certificate. In many cases, there is no other validity constraint
needed. However, for those other cases, the Online: directive is
provided.
4.1.10 Online
The Online: validity option gives the location of a remote service
which will pass judgment on the current validity of a certificate.
Details of such a service have not been specified at the time of this
draft. There is an open issue about whether we should include
specification of one or more such services beyond merely making room
for such specifications in the certificate definition.
Ellison, Frantz, Thomas [Page 26]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
4.1.11 Signature
A signature expression can refer to anything, but typically a
certificate body. If the object hash is used (as expected), that
hash must use the same hash algorithm specified in the signing key.
In that case, the hash value given in the Signature expression is the
one which is to be used to verify the signature.
4.1.12 Bundle
A bundle expression is provided only for convenience, in case someone
wants to bundle a set of public keys and certificate bodies and
signatures into one expression for communication.
4.1.13 <pub-key>
A public signature key expression, for example:
(K: (RSA-SHA1-PKCS1: &03 =gJVtABwLSwwTVM0tg1QPgsOVUoA5EjPz-
=UtNKU3PLElkMk0IAE0yhyy0zYuwVSnQzFEvM0hSns1OKzC08AO0SB84yUsDTgDnL-
=fAyVYtRCHAyPlW0NTDPKcksSh9Tt9EwuQ1SsEgAtMy0XQAAKSxVtA4KODLkzjQzz-
=VFIL00pUc9J= ) )
defines a public key algorithm, a hash algorithm and a padding method
(PKCS1 in this example).
A public key can be transmitted at the top level of a communication.
In that case, it is assumed that the key is referred to by hash in
the body of one or more certificates in the same communication.
4.1.14 Hash
A hash expression, for example:
(H: SHA1 =SxVtA4KODLkzjQzzVFIL00pUc9J= )
or
(H: SHA1 =SxVtA4KODLkzjQzzVFIL00pUc9J= http://ietf.org/ )
gives a hash algorithm name and a hash value of some object.
Optionally, the hash expression also gives a URI of that object.
Ellison, Frantz, Thomas [Page 27]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
4.1.15 <secret-sig-key>
A secret signature key expression, for example:
(HMAC-SHA1: &17fa34017c320401 &75e3391ac90d0a38 )
gives the secret key values for computing a MAC, keyed hash or
encrypted cookie, to permit a symmetric algorithm to be used for
signatures. This is expected to be faster than a public key
algorithm, but is limited to cases where the signer and the verifier
have mutual trust.
4.1.16 Fully-qualified-name
A fully qualified SDSI name, for example:
(FQN: (H: SHA1 =SxVtA4KODLkzjQzzVFIL00pUc9J= ) fred sam )
specifies a key (and therefore its name space) for the first name in
the list ("fred" in this example). That first name can then be
resolved to a key and the process recurses until the FQN is reduced
to a key. The example above might reduce to:
(FQN: (H: SHA1 =yy0zYuwVSnQzFEvM0hSns1OKzC0= ) sam )
etc.
4.1.17 Ref
A Ref expression is a relative name. It is converted to a fully
qualified SDSI name by using the Issuer of the certificate of which
it is a part as the key defining the name-space.
(Ref: joe fred sam)
might become
(FQN: (H: SHA1 =SxVtA4KODLkzjQzzVFIL00pUc9J= ) joe fred sam )
for example.
Ellison, Frantz, Thomas [Page 28]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
4.1.18 Date
A date field is an ASCII byte string of 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. For internal use, it is treated as a
normal byte string. Dates are compared as byte string comparisons.
4.2 Primitives
Not defined in the BNF above are the primitives: byte-string and
token.
4.2.1 byte-string
A byte string is the general atomic element of a list. It can be
expressed in a number of different ways, in ASCII S-expressions:
4.2.1.1 token
A token is a sequence of printable characters other than parentheses,
braces, single or double quotes, square brackets, hash mark, equal
sign or ampersand. It may not start with a digit or end in a minus
sign. Such a token does not need to be quoted.
4.2.1.2 quoted string
A string not containing a double quote can be quoted in double
quotes. A string not containing a single quote can be quoted in
single quotes.
4.2.1.3 hex string
A byte string can be represented in hex by preceding the hex
characters with an ampersand, "&", and terminating it with a blank.
Ellison, Frantz, Thomas [Page 29]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
4.2.1.4 base64 string
A byte string can be represented in base64 by preceding it with an
equal sign, "=", and terminating it with a blank. The base64 string
must be a multiple of 4 characters in length, although it may end
with "=" character(s) to show that it is short 1 or 2 bytes of being
a multiple of 3 bytes in binary.
4.2.1.5 literal binary string
A byte string can be represented as a literal string of binary bytes
by prefixing it with a length and a colon, ":". The length is
expressed in base 256, prefixing each byte of the length with a hash
mark, "#".
If "\001" stands for the byte 0x01, also known as ^A, #\001:"
represents a byte string of 1 byte holding the double quote
character. A length #A#B: would start a literal byte string of
length 16706.
4.2.1.6 concatenation of strings
A byte string, in any of the forms above, can be continued by
following it with the hyphen, "-", and then another byte string. The
two byte strings do not need to be encoded in the same style. They
are represented internally as a single string.
4.2.2 Display information
A byte string may be prefixed with an optional piece of display
information. This is in the form:
<display-info>:: "[" <param> "]"
The display information is assumed to give information about how to
display the byte string. For example, we envision strings like:
[utc-8], [unicode], [jpeg], [gif], [wav], etc. The content of the
display info is allowed to be an S-expression, in case we encounter
display commands which need parameters, but for now we expect it to
be a simple name.
Ellison, Frantz, Thomas [Page 30]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
4.2.3 List counts
A list can be preceded by a count (of the form #<byte>#<byte> but
with no ":"). This is for informational use -- primarily out of
consideration for devices which want to allocate arrays to hold lists
rather than store them as linked elements.
4.3 Binary (canonical) form
Any of these S-expressions which is hashed is to be converted to
binary form prior to the hash. This gives a canonical form and also
reduces the size of the expression to save time in case the hash
function is expensive.
The binary form can also be used to transmit certificates whenever
the communication rate into a device is limited or there is no reason
to keep certificates human readable.
4.3.1 Byte strings
All byte strings are expressed as binary strings (preceded by length
byte(s) and ":") and therefore there is no need for blanks to
terminate strings.
Continuation of byte strings is never used in binary form.
4.3.2 List counts
In packed binary form, for hash purposes, there are no list lengths.
4.3.3 blanks
In binary form, there are no blanks.
Ellison, Frantz, Thomas [Page 31]
INTERNET-DRAFT Simple Public Key Certificate 25 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, described above in section 4.1.7.
5.1 Member-of-issuer
(Moi:)
This <auth> grants the Subject all the authority of the Issuer. It
is anticipated that this <auth> will be used to delegate permissions
to a temporary signing key or to indicate members of a group (where
the Issuer is the group).
5.2 Name
(Name: fred)
This <auth> defines a SDSI name in the Issuer's name-space, in this
example "fred". The Subject of the certificate is assumed to reduce
to the key for that name and most likely to be that key.
5.3 Member
(Member: faculty)
This <auth> declares that the Subject is a member of <group> where
<group> is a name in the Issuer's name space. This is a SDSI group
definition, since SDSI groups had only names in some name-space.
Native SPKI uses a public key as a group name and the (Moi:) <auth>
for delegating privileges to group members.
Ellison, Frantz, Thomas [Page 32]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
5.4 FTP
(FTP: cybercash.com cme )
This <auth> indicates that the Subject has permission to do FTP into
host cybercash.com as user cme.
5.5 HTTP
(HTTP: http://acme.com/company-private/personnel/ )
This <auth> gives the Subject permission to access web pages which
start with the given URL.
5.6 TELNET
(TELNET: erols.com spinne )
This <auth> gives the Subject permission to telnet into host
erols.com as user spinne.
5.7 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
Ellison, Frantz, Thomas [Page 33]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
5.8 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>
This is specialized enough not to be pre-defined. E.g., one might
use:
(Auth: Dating <params>)
5.9 Authority to spend money
(Auth: Spend <bank> <account> <amount> )
indicates that the subject has authority to authorize spending up to
<amount> per electronic check from <account> at <bank>.
For reduction of two certificates with this <auth>, if any field is
present in one and not the other, that field is copied to the <auth>
of the result. If present in both, <bank> and <account> must be
equal. The <amount> byte string is taken to be ASCII of a floating-
point decimal number and if present in both <auth>s, the <amount> of
the result is the minimum of the two input <amount>s.
Ellison, Frantz, Thomas [Page 34]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
Issues
1) Should we require that all certificates be signed by both Issuer
and Subject, when the Subject reduces to a key? [When the
Subject is a non-key object, it can't sign.]
2) Can the Signature: object support blind signatures with
algorithms other than RSA?
3) Should we keep the final ":" in field names? These are always
the first names in a list and the ":" seems to be a carry-over
from RFC822 without a real purpose.
4) Should we continue to lump public key algorithm, hash algorithm
and padding algorithm together in one pub-key-name? This could
lead to an explosion of names. Of course, on the other hand
this might reduce the number of competing algorithm/hash/pad
mixes and simplify code.
5) Should the delegation parameter be integer or boolean?
6) Are object names (e.g., "Issuer:") case sensitive?
7) Should we allow multiple <auth>s in one cert? It saves space
and time, maybe, but could constitute a privacy threat and may
complicate the cert reading code.
8) How much can we specify the <online-test>? Are there only a
handful possible/desirable tests, that we can fully spell out,
or do we need to leave that open for invention?
9) How many pre-defined <auth>s should we bother defining?
10) If the Subject is a hash of a Bundle of hashes of keys, does
this mean that the cert applies to all keys in the bundle?
11) If the Subject is a hash of a file and the file contains hashes
of other things, does the cert apply to the other things?
12) Do we want to include validity fields for private key dates, as
was done with X.509v3?
13) How do we want to name algorithms? One possibility is to define
a few common ones (ones we want to encourage everyone to use for
interoperability reasons) and allow others to be defined as URIs
pointing to the definition of the algorithm.
Ellison, Frantz, Thomas [Page 35]
INTERNET-DRAFT Simple Public Key Certificate 25 Mar 1997
14) Should we restore the explanation of [ECR] and define a <valid>
field option for it? This was removed from this draft in the
interest of simplification.
15) Should we allow Object as an optional element of the Signature
expression, or force that block to give the Object's hash?
16) Should we define an RSA signature algorithm with no hash and no
padding, to hold verbatim objects being signed (assuming they
are small enough)?
17) What is the difference between the Member: and Name: <auth>?
Can they be combined into one?
Ellison, Frantz, Thomas [Page 36]
INTERNET-DRAFT Simple Public Key Certificate 25 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 37]
INTERNET-DRAFT Simple Public Key Certificate 25 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 38]
INTERNET-DRAFT Simple Public Key Certificate 25 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 30 September 1997.
Its file name is draft-ietf-spki-cert-structure-01.txt
Ellison, Frantz, Thomas [Page 39]
