[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Top SDSI issues
-----BEGIN PGP SIGNED MESSAGE-----
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
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.
Ron has suggested that we define a simple set of instructions, maybe
encoded
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
propagate
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
imaginations.
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQCVAwUBM7WL4lQXJENzYr45AQFdrQQAhZdZDCTxZmvx1ytNnW4dwsn/v/L0x+pB
7sDpyM4ZogeUFPZn9J7vT9J95XWzaJAsdpnEdCJTH8mSoxGXLsewbG3DniwQBCZ9
TeqVp7d0uD5vVFhF9oAIr2VZmky+P2h5rg9bzpmF/l7LavzHpNjhnypB0KcNzz4n
n3pTt1UT5P0=
=N7gY
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|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 |
+------------------------------------------------------------------+
References: