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

Re: IETF spki meeting minutes

This has got to be some kind of record.  On behalf of those who could
not make the meeting, thanks!

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

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

[lots more really good discussion omitted .... ]

I'm glad to see some agreement with my fears on this.  I had just felt
that it was only because of my relative lack of depth in these fields,
so I was sort of quietly dropping out of the discussion, hoping that
somebody out there was smart enough to make some sense of it.

In some early conversations on the topic of chain reduction, with its
necessary intersection logic, I felt this was really pretty complex.  I
was glad to see that some more experienced minds got into the discussion,
but it still seems hard.  I had never actually envisioned that logic
making its way into the standard for certificates themselves; it seems
a natural place to break into another, later, specification.  It is
clearly needed, but does it need to be in a cert format specification?

Another simplifying matter:  One of my early assumptions, and repeated
assertions, has been that PolicyMaker could be used in lots of places,
such as threshold signature schemes in particular, where straightforward
chain reduction was not possible.  This could be another place to simplify;
don't make threshold schemes part of the original spec.

It seems that most everyone thinks of these two items as standing in the
way of implementation, and I have to agree.  Those were two things that I
was not planning to put into my implementation anyway, since I couldn't
quite see how to do them.  The encoding is the main reason I haven't already
done an implementation, but that seems to be stable now.

Other things, such as protocols, also need consideration, and fortunately
no one has tried to put them here.  We need at least one other RFC for
that anyway; I'd like to suggest that we continue work on those things as
separate items, and not hang up the most important initial work.  I seem
to be echoing the attendees...

brian


Brian Thomas, CISSP - Distributed Systems Architect  bt0008@entropy.sbc.com
Southwestern Bell                                    bthomas@primary.net
One Bell Center,  Room 34G3                          Tel: 314 235 3141
St. Louis, MO 63101                                  Fax: 314 235 0162
Follow-Ups: