Minutes by Stefek Zaba ; minor edits by Steve Bellovin -- Policymaker status update Matt Blaze presented an update on the status of Policymaker, both implementation and draft. Draft is "almost ready for circulation"; 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. BadNews: reference implenetation 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. -- WG chair editorialises, comments from the floor: Bellovin editorialises: 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 Dec97, likely location Boston, USENIX to sponsor; call for papers within 2-3 weeks ("watch for it on the net"). -- 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 subjecs to be identfied 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 attck is very low). Draft also adds some info on on-line checks and other minor tidy-ups. -- 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 their 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 - 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 authorisation 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. -- Implementation status 3 people have done partial implementations - one cannot talk in any detail. Marjku-Juhani Saarinen (from SSH) has an implementation under way - halfway through, maybe about 3 weeks to go. The intersection algebra is very unlcear 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. -- 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: discusses format (see draft-ietf-spki-cert-structure-02.txt). Explicit lengths + 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-sepcific" 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: 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 backwards) - 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 which 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" - suggests current solution is both too simple and too complex. E.g., 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 e.g. 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 to the corridor/staircase/bar at about 16:50, following the traditional exhortations to sign the blue sheet...