[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.


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).


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

2.  Notation for Binary Data

      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.

      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.

      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 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

       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

      XXX kivinen: the UNIX time(3) seems to return (days since 1 Jan
      1970) * 86400 + (seconds since midnight) as leap seconds are

    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

    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

   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

   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

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: