[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IETF spki meeting minutes

Draft minutes from spki WG, IETF-39 Munich, mon11aug97

Minutes by Stefek Zaba <stefek_zaba@hp.com>; 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

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 

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