After getting too many people confusing SPKI/SDSI's non-CA certificate issuance with PGP's Web of Trust, I wrote the following web page. http://world.std.com/~cme/html/web.html Feedback is, of course, welcome. - Carl
Carl Ellison writes: > After getting too many people confusing SPKI/SDSI's non-CA certificate > issuance with PGP's Web of Trust, I wrote the following web page. > > http://world.std.com/~cme/html/web.html This page doesn't really define "web of trust". It says, "...PGP incorporates a security fault tolerance feature called the Web of Trust. Under the Web of Trust, multiple different keyholders sign each certificate (each binding between UserID and key), attesting to the validity of that binding. The assumption is that these different keyholders are independent so that even if one of them makes a bad judgment, they won't all do so. It is also assumed that no false binding will have more than the specified web of trust number of signatures." This is focussing on the idea of using multiple partially trusted introducers in order to build confidence in a binding between key and name. However I think the defining characteristic of the web of trust goes beyond this aspect. If we look at the name, what we have first of all is a web. This is a network of interconnected elements. Mathematically, it is a graph. But the name "web" implies a certain kind of random structure to the graph. It is not hierarchical, it is point-to-point. End users connect to other end users within the web. Secondly, the web connections indicate "trust". Here I think the term is a misnomer within the PGP context where it was created, because actually the connections in the PGP case don't show trust, they show validity of(Continue reading)
As a further follow-up, here is a long message I wrote for another mailing list a year ago proposing a way to think of the relation between identity certification systems like PGP, and authority certification systems like SPKI: The problem with key-centric approaches is that it is not clear that a key has behavioral attributes. In some cases it does, as when there is an automated server which uses its key in specified and limited ways under the control of some automated program. But in many or most cases, keys are wielded by humans; they are the slaves of humans, and the keys have no say in how they are used. It is humans, ultimately, who bear the responsibility for what the keys do, and it is humans which should be involved in trust-related decisions. I see it like this. End-use attributes can be put directly on keys in many cases. A given key is authorized to unlock a door, or to request a web page. But once you start trying to delegate authority, it is best to start using names. Then there needs to be a specific subset of the PKI whose only job is to associate names with keys. This subset is what PGP tries to address. Given this subset as a base, you can freely interchange key-centric and name-centric certificates. You can give authorization to use some resource by name, or by key. You can give meta-authorization to delegate the use of some resource, and in this case it is probably best to do it by name. I believe, contrary to the SPKI philosophy, that most authorization and credential decisions are best handled by name rather than by key. That is human nature, that is what we are familiar with. You can't punish a key, you can't argue with it or complain when it does something inappropriate. We have evolved social systems which allow for cooperation(Continue reading)
To all, I've been looking at the S2K Usage (3.6.1) and, when using twofish as the symmetrical algorithm (in say a type 0x00 S2K Usage), what do you do if you want to use a 256 bit session key to encrypt the secret key? I'm assuming here that S2K will only allow a session key equal to the symmetrical algorithm block size... If this is correct, what happens when 64 bit symmetrical algorithms are used...is the session key length limited to only 64 bits? Or... Do you decide what length of the S2K session key to use (in your program), then when the secret key needs to be extracted from the secret key-ring, just keep trying multiple session key lengths in block size multiples (as generated from the S2K specifier) until the checksum checks out OK? It seems it would be a lot easier (maybe less secure?) if a session key length was specified somewhere. Cheers. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia(Continue reading)
Erron writes: > I've been looking at the S2K Usage (3.6.1) and, when using twofish as the > symmetrical algorithm (in say a type 0x00 S2K Usage), what do you do if you > want to use a 256 bit session key to encrypt the secret key? I'm assuming > here that S2K will only allow a session key equal to the symmetrical > algorithm block size... No, it doesn't have this limitation. You hash the plaintext and extract whatever size session size is needed from the hash. If necessary you do multiple hashes and concatenate them. > Do you decide what length of the S2K session key to use (in your program), > then when the secret key needs to be extracted from the secret key-ring, > just keep trying multiple session key lengths in block size multiples (as > generated from the S2K specifier) until the checksum checks out OK? > > It seems it would be a lot easier (maybe less secure?) if a session key > length was specified somewhere. The session key length is always known. It is part of the algorithm identifier. See section 9.2. Hal
At 09:54 PM 5/09/2000 -0700, hal <at> finney.org wrote: <snip> > > Do you decide what length of the S2K session key to use (in your program), > > then when the secret key needs to be extracted from the secret key-ring, > > just keep trying multiple session key lengths in block size multiples (as > > generated from the S2K specifier) until the checksum checks out OK? > > > > It seems it would be a lot easier (maybe less secure?) if a session key > > length was specified somewhere. > >The session key length is always known. It is part of the algorithm >identifier. See section 9.2. Oh... I didn't link section 9.2 with the session key length of an S2K...maybe in the next revision of 2440, a simple reference to 9.2 in section 3.6 would help others who are also wondering what session key lengths to use with the S2K's. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia(Continue reading)
Hi, This is off topic but should be of some interest to list members. It seems that Qualcomm is bouncing all messages containing attachments. This unfortunatly includes PGP/MIME messages or any multipart MIME formats. Below is the bounce message from Qualcomm: Greetings, Your recent email message to QUALCOMM has not been delivered due to the attachment it included. QUALCOMM does not allow email with certain types of attachments due to the possible presence of a computer virus in these files. Please resend your message without any attachments or compress your attachment before sending it. We apologize for any inconvenience. The QUALCOMM Postmasters -- -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html E-Secure: http://www.openpgp.net/esecure.html ---------------------------------------------------------------(Continue reading)
I'm back from vacation, but not completely un-jetlagged. I want to put out a draft, and I'd like to do it relatively quickly. I have a suggestion to make about speeding it up. Normally, I walk through all the mail on the list, making changes to the base draft. Then people tell me what I spazzed on, and I fix it. Since we don't have a current draft, I feel the need to put one out quickly. Here's a proposal for how to get one out quickly: I'll tidy my current draft, in the state that it's in. I'm only going to change the structural things I need for a new draft (dates and the like) and then I'll send it in as the next 2440bis draft. I'll then start looking through old conversation, and so will you, if you've had a suggestion. If I didn't get your change, tell me, and I'll edit it. As usual, it's easier for me to deal with a suggestion that says, "Please change X to Y" than one that says, "Please change X." Does this sound good? Jon
On Wed, 20 Sep 2000, Jon Callas wrote: > Does this sound good? Yes. werner -- -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de
Jon, At 07:06 PM 20/09/2000 -0700, Jon Callas <jon <at> callas.org> wrote: <snip> yes it does... Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc <at> comasp.com
RSS Feed9 | |
|---|---|
6 | |
11 | |
43 | |
5 | |
5 | |
5 | |
13 | |
30 | |
4 | |
25 | |
4 | |
1 | |
5 | |
14 | |
3 | |
11 | |
60 | |
8 | |
2 | |
62 | |
52 | |
1 | |
1 | |
20 | |
16 | |
14 | |
31 | |
40 | |
68 | |
22 | |
41 | |
1 | |
72 | |
26 | |
1 | |
6 | |
1 | |
26 | |
52 | |
34 | |
1 | |
17 | |
4 | |
7 | |
20 | |
11 | |
32 | |
10 | |
13 | |
23 | |
64 | |
49 | |
32 | |
68 | |
47 | |
63 | |
102 | |
100 | |
49 | |
13 | |
53 | |
47 | |
36 | |
101 | |
73 | |
6 | |
4 | |
51 | |
1 | |
17 | |
2 | |
13 | |
36 | |
101 | |
23 | |
38 | |
41 | |
16 | |
54 | |
3 | |
31 | |
66 | |
72 | |
51 | |
30 | |
121 | |
7 | |
39 | |
1 | |
11 | |
11 | |
81 | |
57 | |
16 | |
5 | |
75 | |
154 | |
6 | |
46 | |
51 | |
26 | |
37 | |
19 | |
50 | |
131 | |
42 | |
7 | |
17 | |
53 | |
62 | |
47 | |
48 | |
34 | |
25 | |
45 | |
13 | |
29 | |
78 | |
65 | |
56 | |
18 | |
30 | |
9 | |
55 | |
26 | |
15 | |
25 | |
11 | |
11 | |
58 | |
37 | |
58 | |
105 | |
47 | |
34 | |
37 | |
23 | |
10 | |
16 | |
96 | |
10 | |
157 | |
121 | |
110 | |
94 | |
201 | |
30 | |
62 | |
136 | |
372 | |
363 | |
127 | |
71 | |
12 | |
1 |
