2.6.9 Simple Public Key Infrastructure (spki)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.


Steve Bellovin <smb@research.att.com>
Perry Metzger <perry@piermont.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion: spki@c2.net
To Subscribe: majordomo@c2.net
In Body: In Body: subscribe spki [email address]

Description of Working 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.

Goals and Milestones:

Feb 97


Submit initial requirements document as an Internet-Draft.

Mar 97


Submit initial specification as an Internet-Draft.

Apr 97


Meet at Memphis IETF.

May 97


Submit SPKI specifications to IESG for publication as an RFC.


No Request For Comments

Current Meeting Report

Minutes of the SPKI Meeting

Reported by Stefek Zaba <stefek_zaba@hp.com>; minor edits by Steve Bellovin

I. Policymaker Status Update

Matt Blaze presented an update on the status of Policymaker, both implementation and draft. Draft is "almost ready for circulation," and will be ready for (well before - ed) Washington IETF. Also, Joan Feigenbaum and Martin Strauss have done some analysis work on provability of the Policymaker interpreter. Their paper is due for circulation shortly.

Bad News: reference implementation is *not* yet available. Playware available on request against a "yes it's broken" disclaimer. Send email to policymaker@research.att.com. Only porting problems stand in the way - true yacc dependency (bison and cousins won't do). This misfeature to be fixed RSN.

II. WG Chair Editorializes, Comments From the Floor

Bellovin editorializes: comments received that "S" in SPKI no longer "simple," possibly "SDSI" but not clearly. Matt Blaze agrees and suggests "X.510" as new working name :-)

Temporary adjournment taken while Tatu struggles with the slidemaking capabilities of the terminal room.

Timetable? Well, intention *did* exist to put forward a draft to become part of standards process from this meeting. Absence of Carl Ellison and Tatu's doubts mean that this has slipped.

Matt Blaze explains one important difference between SPKI and SDSI (in answer to a comment in the spirit of "this is so complex, isn't it just SDSI in drag") - SPKI is an authentication scheme, while SDSI was for identification.

Clarification requested for blind signature status - draft claims it'll work but two people, including Marjku-Juhani who is doing an implementation from the spec (see later) note that they do not in fact work.

Pre-announcement: Matt Blaze and Perry Metzger will be doing a conference/working group on PK infrastructure and trust management in April 1988, position papers need to be in by December 1997, likely location is Boston, USENIX to sponsor; call for papers within 2-3 weeks ("watch for it on the net").

III. Tatu Speaks on the Current Draft

Tatu reports major improvements from previous draft. Canonical format is ONLY one supported for SPKI data: essentially binary, length-prefixed. Algorithm for 5-tuple reduction specified, appears in the draft. Star-forms have been added, allowing specs for intersections/unions/predicates to be specified. Powerful, but admittedly complex (8 pages of very dense spec). K-of-N cert (a threshold scheme) has been added: allows N subjects to be identified and require that K <= N keys be used to sign messages to the verifier. Increases security by reducing exposure of a single key. Also has the following advantage: suppose major key, e.g., Verisign private signing key, is compromised: now the blackmail value is *large* indeed; whereas, for a threshold scheme, value from a single key compromise is essentially nil (and practicality of simultaneous attack is very low). Draft also adds some info on on-line checks and other minor tidy-ups.

IV. Discussion on Current Draft

Floor opened for discussion on the draft. One voice says, "it's long". Other voices agree that "simple" isn't accurate any more. No one was willing to put his or her hand up to the opinion that it is now a "simple" pki. Doubt expressed (from Eric) that the "pulling things out" method for simplification will work and suggests that admitting a mistake has been made (perhaps rhyming with "Pudsey" :-) and maybe doing a grand reset would be the right thing.

Matt Blaze recounted a discussion of a year ago between him and Carl where Carl suggested the full power of Policymaker was too general and something simpler was needed, but the current accretion of features has created something big again. Maybe an SPKI-lite is needed. Marjku also points out that the full implementation is too big to verify, and that the intersection algebra is going to be hard. Tatu notes that the S-expression intersection combination is further complicated by star forms - algorithms "aren't trivial," *probably* polynomial time. But Carl and RonR note that you do not need to compute the intersection: you are always computing whether a fully-ground TERM is a *member* of (multiple) predicate specs, and you can cascade the tests.

Floor requests the WG chair to say whether an X.509 or a SDSI cert is harder to handle. "On advice of counsel", Bellovin replies "the complexities are different". SPKI is simple to parse (but semantics are another matter!) Also, X.509 does not carry the authorization idea - SPKI does. Problems with X.509 are not ASN.1, suggests GUY-IN-BLACK-SITTING-NEXT-TO-MATT: rather that the structure is static and only uninterpreted random octet-strings can be added.

General consensus that "the path to simplicity has been lost" - WG chair suggests taking this to the mailing list.

V. Implementation Status

Three people have done partial implementations; one cannot talk in any detail. Marjku-Juhani Saarinen (from SSH) has an implementation under way - halfway through, maybe three weeks to go. The intersection algebra is very unclear and is an unpleasant barrier to effective implementation in its current form. It's written in C, uses bits of reference code. Third implementation is by Tatu: has 800 lines of code which parse the binary datatypes, does not include hashing or crypto operations, and the minor detail of compiling the code has not yet been seen to.

VI. More Discussion on Draft/Current Status

Suggestions for simplification requested, maybe more hands to assist Ron, Carl, and Tatu? Marjku suggests "membership operator" as one possible direction. Tatu speaks a bit more on motives for introducing the binary-only representation and discusses format (see draft-ietf-spki-cert-structure-02.txt). Explicit lengths plus type tags - ignore the field if you don't understand the typetag. Some common fields, e.g., times issued and expired, extra constraints w.r.t. CRLs/revalidation, and a lump of "type-specific" binary data, all followed by a signature.

For the case of certs, the type-specific data is:

· int nsubjects
· PRINCIPAL subjects
· int k
· string doi /* domain of interpretation */
· string auth

Note that separate documents describe the treatment of doi and auth for particular usages.

More on K-of-N: in "traditional" case of a certchain, full rights granting goes along the chain:

VII. CAroot -> intermed1 -> intermed2 -> subject

For k-of-N, this "chain" can now fork; and requirement is that where they merge at least "k" separate sigs are present. Algorithm for checking verification is to go backwards from the subject (depth-first search backward) - keep bitvector as you search and a total count. Note that each branch of the depth-first search should terminate at the granter - each separate path that does so terminate causes you to increment the total count. Success overall is when count reaches k; failure when all paths searched and total count still below k. [Minute-taker note - Tatu may want to verify the above sketch, but that's about what I thought I heard him say :-)]

Floor asks "what use is this?" Tatu answers with example of corporate policy requiring 2 of 3 signatures; a PC requires departmental policy key, that requires 2 of 3 corporate key, corporate key requires (say) 8 of 10 from "the" global roots. Removes a single point of compromise. Eric continues to probe the "why" and suggests current solution is both too simple and too complex. For example., sharing schemes that say "must have 2 of people X/Y/Z and at least 5 of the other 7" - suggests this kind of secret-sharing should be put into the *application policy* rather than wiring into the infrastructure, and is not yet clear that algorithm as described correctly implements intent of spec.

Observation from Ted Ts'O - can do the more complex example suggested by Eric by AND'ing the 2 primitives. CA liability risks also reduced by secret sharing, as are costs of protecting each individual secret keys.

Floor expresses a worry that this is a slippery slope: K-of-N may lead to weighted-K-of-N and then to "all other" possible auth-policies. Chair suggests that *purpose* of mechanism is unclear, as well as, (a) do we need K-of-N, we need to consider (b) should base draft specify how K-of-N should be implemented. Tatu argues wide utility may be reason to put this into the base draft. John Schey reports challenges in meeting audit requirements, for example, threshold schemes all the way down to a final money-issuing bank from the Safekeeper-running big bank assoc. WG chair says "let's move this to the mailing list."

Tatu / others suggests complications in the spec (possible candidates for elimination from the base spec) include:

· the star-forms (or at least the set-algebra operations therein)
· K-of-N
· anything which goes beyond "does auth" and "is simpler than X.509"
· SDSI names
· S-expressions :-)

of which the Chair deftly bounced reopening the S-expression religious war and the "anything beyond" suggestions.

Adjournment at about 16:50, following the traditional exhortations to sign the blue sheet.


None Received

Attendees List

Roster Not Received

Previous PageNext Page