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

Top SDSI issues

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

One possibility is to make the client responsible for collecting all
needed certificates and keys, and sending them to to the server.  It
would be preferable to offload any unnecessary processing from the
server to the client anyway, as the server is more likely to be a
performance and reliability bottleneck.  Fetching data over the
network from key servers is the sort of thing that is likely to
severely disturb normal server performance unless asynchronous
connections and other tricky programming techniques are used, and even
then connections sometimes hang due to bugs in TCP/IP implementations.

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

I'm writing more about these; in a couple of weeks I expect to have
something more understandable on paper.

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

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

I agree.  I haven't seen a clear discussion of propagate and
related issues in this context.

Note that in my draft (which has so far only been distributed to a
small number of people) naming and delegation where completely
separate - names were explicitly resolved as part of authorization
verification, and didn't imply delegation.

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

Or, no predefined tag types at all in the base draft; my suggestion is
to just specify a domain of interpretation, and then have the
remaining data be interpreted according to the domain.

We should probably have some common application domains predefined,
but again there is no need to fit them all into a single syntax if
this is not very convenient.

    Tatu

-- 
F-Secure Internet Security Solutions  http://www.datafellows.com/f-secure
Free Unix SSH                         http://www.cs.hut.fi/ssh
Follow-Ups: References: