[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
six-page binary format draft (was: Quick Survey: name certificate syntax)
> For the sake of simplifying the explanation of certificate meaning and
> cleaning up the reduction engine a little, I've been pretty well convinced
> by Ron Rivest's SPKI programmers to separate name certificates out from
> authorization certificates. The difference is that a name certificate is
> always (tag (*)) [and by the stop-at-key rule, (propagate)].
I'll include below a draft that I wrote after the last IETF for a
simplified binary certificate. It is a simplified version of the
binary format draft that I had before the August IETF.
This draft is six pages. It includes
- SDSI names
- K-of-N delegation (threshold subjects), also for names
- authorization certificates
- name certificates (special form of authorization certs)
- Revocation lists (CRL)
The full text is included below. The format is intended to be simple,
fixed (to avoid interpretation problems) and extensible.
Tatu
Network Working Group Tatu Ylonen <ylo@ssh.fi>
INTERNET-DRAFT SSH Communications Security
spki-binary.txt August 12, 1997
Expires in six months
Really Simple SPKI Certificates
Status of This memo
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 and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``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 ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast),
or ftp.isi.edu (US West Coast).
Abstract
This document is a proposal for certificate formats and their semantics
in SPKI.
Tatu Ylonen <ylo@ssh.fi> [page 1]
INTERNET-DRAFT August 12, 1997
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notation for Binary Data . . . . . . . . . . . . . . . . . . . . 2
3. Binary Object Wrapper . . . . . . . . . . . . . . . . . . . . . 4
4. Common Part for Signed Objects . . . . . . . . . . . . . . . . . 5
5. Authorization Certificates . . . . . . . . . . . . . . . . . . . 6
6. Certificate Revocation Lists . . . . . . . . . . . . . . . . . . 6
7. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
This draft is a proposal for a simple binary format and semantics for
the SPKI (Simple Public Key Infrastructure) working group.
The proposal has the following features and goals.
o SDSI-style naming
o Authorizations specified in separate documents
o K-of-N delegation
This proposal is heavily based on ideas from SDSI, SPKI, and
PolicyMaker.
2. Notation for Binary Data
uint32
A 32-bit unsigned integer, represented as four bytes, MSB first
(network byte order).
For example, the value 699921578 (0x29b7f4aa) is represented as 29
b7 f4 aa.
bytestring
Arbitrary length binary string. Strings are allowed to contain
arbitrary binary data, including null characters and 8-bit
characters. They are represented as a uint32 containing its
length (number of bytes that follow) and zero (= empty string) or
more bytes that are the value of the string. No terminating null
character is included in the string.
For example, the string "testing" is represented as 00 00 00 07 t
e s t i n g.
mpint
Multiple precision integers in two's complement format,
represented as a bytestring, 8 bits per byte, MSB first. Negative
numbers have one in the highest bit of the first byte. If the
highest bit would be set for a positive number, the number must be
Tatu Ylonen <ylo@ssh.fi> [page 2]
INTERNET-DRAFT August 12, 1997
preceded by a zero byte. Unnecessary leading zero or 0xff bytes
are not allowed. The value zero has zero bytes of data.
For example, the value 694531781388612263 (0x9a378f9b2e332a7) is
represented as 00 00 00 08 09 a3 78 f9 b2 e3 32 a7.
time
Time values are needed e.g. for expiration dates and timestamps.
In this proposal, all times are represented as seconds from
January 1, 1970, 00:00 UTC. The value is represented as uint32.
This format allows operation until year 2106. Before then, a new
certificate format version will need to be defined to add more
space.
Rationale: Using 32-bit binary values allows easy processing and
comparison on existing 32-bit machines. This makes implementation
easier and reduces errors. Standard functions for processing
times in this format are available at least in C, C++, Java, and
Perl.
XXX kivinen: the UNIX time(3) seems to return (days since 1 Jan
1970) * 86400 + (seconds since midnight) as leap seconds are
unpredictable.
NAME: Unique Names
Certain unique names are used in the specification to name e.g.
algorithms and object formats (note: this is different from names
in key namespaces). These names are bytestrings. Names
containing a colon ':' or at sign '@' are reserved for user
extensions; these would typically be URIs or have domain name
attached to have conflicts. Other names are assigned to IANA for
allocation. Names should only contain printable US-ASCII
characters.
PRESENTED: String with presentation Hints
Type for a string with a presentation hint (MIME type).The
representation is as follows:
bytestring presentation hint
bytestring value
The presentation hint is a MIME type. It may be empty, in which case
"text/plain; charset=iso-8859-1" is assumed. The default is
substituted before comparisons, but not before hashing the object
containing it. The presentation hint takes part in comparisons. The
presentation hint should be written in all lowercase, unless
otherwise mandated by the MIME specification. Case is significant
for both the presentation hint and the value (bitwise comparison is
used).
The value is the data to be presented, as binary data (MIME Content-
Transfer-Encoding: binary). It may be a textual, directly printable
Tatu Ylonen <ylo@ssh.fi> [page 3]
INTERNET-DRAFT August 12, 1997
string, or something else. However, it may also be arbitrary 8-bit
binary data.
PUBLICKEY: Public Keys
Public keys are represented as follows:
NAME key type
bytestring type-specific key data
bytestring location (URI)
Format of public keys depends on the algorithm used. The level of
abstraction for key types is that the operation takes in an
arbitrary-length document (possibly in parts) and produces a binary
blob that is the signature. In other words, it combines a hash,
signature algorithm, padding, and encoding.
The location is optional, and specifies the location of the
appropriate key server(s) if present. It should be empty if not
specified.
The rsa-md5-pkcs1 key type specifies RSA encryption, MD5 hashing of
the document, PKCS-1 padding and encoding for the data on which the
public/private key operation is performed, and PKCS-1 encoding for
the resulting signature. The type-specific data is as follows.
mpint modulus
mpint exponent
The dss-sha key type specifies DSA with SHA, with padding in
accordance to the DSS (Digital Signature Standard). XXX check the
encoding; do we need to refer to PKCS-1 or something else?
Additional key types may be defined in separate documents.
PRINCIPAL: Key Reference
A principal can be a public key or a name in a key's name space.
Note that the mapping is not necessarily one-to-one. The
representation is as follows:
PUBLICKEY base key
uint32 name_count (often zero)
PRESENTED name } repeat name_count times
This type is used to express SDSI-like name references of the form
"(<key> n1 n2 ... nk)". Names are stored in the same order as they
appear in the SDSI S-expression.
The names should be interpreted as constraints rather than functions:
each name may refer to multiple principals.
3. Binary Object Wrapper
Every SPKI object is of the following format. When a client sends
Tatu Ylonen <ylo@ssh.fi> [page 4]
INTERNET-DRAFT August 12, 1997
certificates, it sends a number of these objects concatenated together.
uint32 magic number 0x53504b49 ("SPKI")
bytestring object data (payload)
Object data is required to start with a bytestring specifying the object
type. Any unrecognized objects must be ignored.
4. Common Part for Signed Objects
A signed object begins with data common to all objects, continues with a
shared part that is common to all certificate types, and typically also
contains type-specific data. The common part has the following format.
No additional data may follow the signature field.
NAME object type (e.g. "cert-1")
PUBLICKEY issuer
time validity start (first second when valid)
time expiration time (first second when no longer valid)
bytestring additional validity conditions
bytestring type-specific data
PRESENTED comment
bytestring signature
The comment field is not used for any automatic purpose. However, it
may be displayed when specifically requested by a user interface.
The signature is computed over the preceding data, starting from object
type.
The additional validity data in signed objects can be used to specify
CRL and other conditions for object validity. Objects that contain
unrecognized validity conditions should be ignored. The data consists
of string pairs:
NAME condition_name } repeat as many times as needed
bytestring data }
Many applications require certificates to be verified against a
periodically published certificate revocation list (CRL). This is
indicated by a condition name "crl", and the following data (inside the
"data" string).
bytestring location of CRL (URI)
PUBLICKEY CRL signer key
The certificate is to be accepted only if the verifier has a valid CRL
available from the given signer, and the certificate is not listed in
the CRL.
XXX specify which URI forms are allowed.
Online checking is specified by a condition name "online". XXX specify
contents and protocol later.
Tatu Ylonen <ylo@ssh.fi> [page 5]
INTERNET-DRAFT August 12, 1997
5. Authorization Certificates
Authorization certificates are used to delegate authorization.
Delegation may be to a directly specified key, or to keys specified
indirectly by a name.
Delegation certificates are signed objects of type "cert-1" and the
following type-specific data (this is within a bytestring in the common
signed object format):
NAME domain of interpretation for authorization
bytestring authorization
uint32 may_delegate, 0=no, 1=yes
uint32 num_required (k), normally 1
uint32 num_subjects (n), normally 1
PRINCIPAL subject } repeats num_subjects times
The meaning of the authorization field is determined by the domain of
interpretation. The domain defines the syntax and semantics of the
authorization field. Domains are defined in separate documents; no
semantics are given for the authorization field in this document (except
for name certificates; see below).
6. Certificate Revocation Lists
Certificate revocation lists are signed objects of type "crl-sha1-1" and
the following type-specific data:
bytestring sha1_hashes_to_revoke
The sha1_hashes_to_revoke field contains SHA-1 hashes of certificate
object payloads (from object type to beginning of signature). Every
certificate whose hash is in the list is to be revoked. Each hash is 20
bytes; there are no delimeters between hashes. The string length must
be a multiple of 20 (otherwise the CRL must be ignored, causing the key
to be ignored because of no valid CRL).
A base CRL expires when its signed object expires. CRL objects may not
have additional validity data (the field must be an empty string).
7. Names
Names in a key's namespace are defined using authorization certificates
with the domain of interpretation "name". The authorization field has
the following format:
PRESENTED name
This assigns the given name to the subject of the certificate in the
issuer's namespace. If the same name is assigned to several keys, it
forms a group.
Tatu Ylonen <ylo@ssh.fi> [page 6]
Follow-Ups:
References: