[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Certificate Variability
In the spki discussion to date, at least two "straw-men" certificate
structures have been offered up to serve as anchors for discussion.
I reprise them here, and follow with some observations and questions
for the spki group to consider.
If I misrepresent anyone's work here, I hope that the authors will let
me know.
The first, I believe, was offered by Carl Ellison. This "generalized"
certificate has the following minimal structure:
Certifying-key: <KEY_ID>
Signed-key: <KEY_ID>
Validity: <DATE_RANGE>
Meaning: <variable structure>
(cert-key signature appended).
In Carl's envisaged use, "KEY_ID" would be, say, a hash of the indicated
public key, suitable as an index for look-up where provision for such
access has been pre-established. Otherwise this field would contain
additional sub-fields to provide a means for retrieval.
E.g. KEY_ID = <keyhash, owner, url ...>
The "Meaning:" field would convey the key-usage or key-restrictions, in a
format appropriate to the reading-entity (human/machine) to delimit just
what is being certified. A standard codification of the "Meaning" field
would make for lively debate.
Another target was offered recently by Paul Leach:
Cert-Name: <DNS-name>
Issuer-Name: <DNS-name>
Key: <base64>
Expires: <RFC1123-date>
Serial: <RFC822-msgID>
Sig: <base64>
Here, Cert-Name is a fetch-point unique to this certificate, and Issuer-Name
provides something similar for obtaining the Cert-key (and/or contacting the
issuing party.) Paul offers that this certificate carries with it an implicit
policy, limited exactly to "the issuer was shown a key and generated a unique
DNS name which it bound to that key."
Unlike Carl's generalized cert, where "Meaning" can reiterate or add
explicit bindings, Paul's certificate is restricted to the implied binding
of key-to-fetch-point. Using Carl's structure, one could approximate Paul's:
(pardoning my syntactic liberties)
Certifying-key: null,null,(issuer's)DNS-name
Signed-key: key-value,null,(cert-fetch)DNS-name
Serial: RFC822-msgID
Validity: now < Expire_Date
Meaning: null
(cert-sig appended)
Some Observations and Questions:
--------------------------------
Broadly, I understand the goal of SPKI to be to provide a fresh look at the
issues regarding PKI models, ideally leading to a more spartan alternative
to the (Vogon-Class Cruiser) X.509 certificate. Judging by my read on the
postings to this list, some of the qualities of this alternative might be:
1. Less (biased toward)/(encumbered by) a given trust-model.
2. Less fields/structure absolutely required for processing.
3. Less dependent upon a sophisticated engine to parse/process.
4. Support for operations where humans may or may not be closely
"in the loop".
In short, an "atomic" key-enabling device capable of servicing a wide range
of lightweight needs. The desire for (1) is somewhat at odds with the other
requirements, as it implies a degree of flexibility in the specified binding,
and further certificate variability.
A generic question for this list might be ...
When are two competing certificate models so different that they
must belong in "different worlds", rather than be subsumed within
a generic certificate handling framework?
To provide an example, suppose all types of certificates were required
to reserve the first N bytes to a "certificate type specification" which
conveyed to any cert-handling system answers to these questions:
1. Does this cert have the semantic content I need?
(Is it Key-centric, where I expected an Identity cert?)
(Is its Validity based solely on CRL, while I can only
handle short-term, non-CRL type certs?)
2. Does this cert-body have a structure/encoding I can parse?
Note that this limited specification could probably be conveyed in some
form of tight ASCII encoding to most everyone's satisfaction.
When these two questions can be answered in the affirmative, the system
would proceed to process the body of the certificate according to the
indicated structural encoding. What I envision here would be a suite
of SPKI-Compliant certificates, some with a loose, string-ASCII format
and variable Meaning descriptions, suitable for human to human processing,
others with minimal, limited fields in a byte-offset binary form for
compactness in, say UDP. Then certificate handling routines might be
deemed "Minimally-SPKI-Compliant" if they can sort the certificates
according to (1) semantic content and (2) encoding type, and (3) properly
handle at least one semantic form and encoding.
With this approach, we may be able to gain consensus on a certificate
"meta-form", develop and refine a few variants, and then let the users
decide what is useful and what gets discarded.
I imagine that some spki certificates will (optionally) support many fields
that are not represented in the above examples. To keep the fields and their
meanings straight, I tend to (mentally) adopt a division of certificate into
parts, at least conceptually if not in structurally, along these lines:
Cert-Spec: (cert-type, version, structure, encoding, ...)
Cert-Info: (cert-ID, issuer, issuer-key, "policy", validity ...)
Binding: (signed-key, "meaning" or key-bound-values ...)
The entire package signed with issuer key for integrity, but the binding
is now explicit.
With this formulation, Carl's generalized cert might be represented by
Cert-Spec:
Cert-Type: spki-A (key-centric)
Version: 1.0
Structure: strings
Encoding: US-ASCII
Cert-Info:
Key: KEY_ID
Validity: DATE_RANGE
Binding:
Key: KEY_ID
Meaning: whatever
(signature)
Paul's cert would be represented by
Cert-Spec:
Cert-Type: spki-B (DNS-centric)
Version: 1.0
Structure: strings
Encoding: US-ASCII
Cert-Info:
Issuer-Name: DNS-name
Serial: serial-number
Validity: DATE_RANGE
Binding:
Key: <base64>
Cert-Name: <DNS-name>
(signature)
O.K., capturing the specific RFC formulations for fields would be needed,
although they may be captured by the standard meaning of "spki-B" or by
an equivalent mechanism.
Please feel free to embellish, diminish, flame, or even agree. Things
seem awfully quiet on this list recently.
___TONY___ (after 8 PM PST, azb@puma.llnl.gov)
Tony Bartoletti LL
SPI Project Leader LL LL
Computer Security Technology Center LL LL LL
Lawrence Livermore National Lab LL LL LL
PO Box 808, L - 303 LL LL LLLLLLLL
Livermore, CA 94551-9900 LL LLLLLLLL
email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL