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

Re: Top SDSI issues


At 02:37 PM 6/28/97 +0300, Tatu Ylonen wrote:
>> 2.  [Hashes of keys]
>>     Use of hashes for keys, or just the raw keys always?  It is 
>>     to use key hashes until and unless problem 1 is solved above 
>>     how to say "I can't process this cert chain because I don't have 
>>     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.

Ron has suggested that we define a simple set of instructions, maybe 
in certificate ordering, so that the verifier doesn't have to search for 
certs -- just follow the client's instructions.  I believe he is writing 
that up this weekend.

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

I plan to put this into an appendix of the draft, for the WG to discuss.

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

I believe there is still only a boolean:
(propagate) means you propagate through the subject, no matter what.
Absense of that means you don't propagate, through keys -- but do 
through name resolutions.

It never makes sense to issue a cert which needs name resolution (whose 
subject is a name) but doesn't permit any following cert.

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

I don't believe we should specify any tags as part of the standard -- just 

give lots of examples for people to emulate and to trigger their 

 - Carl

Version: PGP for Personal Privacy 5.0
Charset: noconv


|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street   PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |