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

Top SDSI issues


Carl --

Butler and I met yesterday.  We felt that the top outstanding issues for
SPKI/SDSI are:

1.  [Request protocol]
    Some description of the request/reject/retry protocol.  How are
    errors and problems reported back to the requestor?  (E.g. bad
    signatures, cert chain problems, missing certs, no values for 
    key hashes, etc...)  In our view, this is the most important missing
    piece.  It doesn't need to be solved at the syntax level, but the
    semantics need to be described.  What are the possibilities?

2.  [Hashes of keys]
    Use of hashes for keys, or just the raw keys always?  It is impossible
    to use key hashes until and unless problem 1 is solved above describing
    how to say "I can't process this cert chain because I don't have the
    key corresponding to one of the key hashes", and how to give the
    key for a key hash in return.

3.  [Thresholding]
    This is the use of threshold schemes, which you and Tatu have been
    exploring, and which Butler and I don't understand yet.

4.  [Longer issuers and cert chain collapsing]
    It would be desirable to define cert chain collapsing pairwise, so that
    the description of how to collapse a cert chain proceeds by induction
    from the base case of collapsing two certs.  At the moment, we can't
    do this, since the result cert may have an issuer with the form
    (ref K1 N1 N2 .. Nk)  where k>1.  Thus, Butler and I feel that it would
    be good to allow such expanded issuers in certs.  This is an issue that
    we addressed before, and decided not to allow such issuers because they
    may seem a bit more complicated to the user.  

5.  [Cert type annotations]
    The SPKI/SDSI are very general critters.  However, a user-interface might
    want to think of these certs as being of different "types" e.g. a 
    name/value type, or a group membership cert.  For SPKI/SDSI to be
    successful, the user interface needs to work well.  The certs need
    to support this by having annotations that specify what conceptual
    type they are for the user.  (This is similar to display types, in that
    they are only there for user interface purposes, and do not affect the
    cert chain collapsing, etc.)

6.  [Unique ID's]
    My recent note proposed (too many) of these, and we need to make sure
    that we have just what we really need and want, and not more.

7.  [Propagation]
    Butler feels that this needs one more review.  

8.  [More tag types?]
    E.g. to handle network addresses. 

9.  [W3C Dig Sig group]
    They are interested in synching with us, if possible.  We'll be meeting
    with them soon to see what might be possible.  Of course, we don't want
    to slow SPKI/SDSI down...

Cheers,
	Ron
Follow-Ups: