From owner-ietf-openpgp@mail.imc.org Sat Sep 2 23:45:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20962 for ; Sat, 2 Sep 2000 23:45:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA23019 for ietf-openpgp-bks; Sat, 2 Sep 2000 19:19:45 -0700 (PDT) Received: from mx.spiritone.com (mx.spiritone.com [205.139.108.5]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA23015 for ; Sat, 2 Sep 2000 19:19:43 -0700 (PDT) Received: (qmail 21356 invoked from network); 3 Sep 2000 02:21:01 -0000 Received: (ofmipd 208.130.241.164); 3 Sep 2000 02:20:39 -0000 Date: 2 Sep 2000 19:21:37 -0700 Message-Id: <3.0.5.32.20000902192137.008eed90@spiritone.com> From: "Carl Ellison" To: ietf-openpgp@imc.org X-Sender: cellison@spiritone.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Subject: web page on Web of Trust Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQA/AwUBObG1sHPxfjyW5ytxEQLT3wCguu1z6pdFKTtrmYwpR7iC/OZPoLQAoOfz 6AJbF4kqSf8vQeCD/5ToiES1 =64cc -----END PGP SIGNATURE----- +------------------------------------------------------------------+ |Carl M. Ellison cme@acm.org http://world.std.com/~cme | | PGP: 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 | +--Officer, officer, arrest that man. He's whistling a dirty song.-+ From owner-ietf-openpgp@mail.imc.org Sun Sep 3 16:46:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11921 for ; Sun, 3 Sep 2000 16:46:21 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA23337 for ietf-openpgp-bks; Sun, 3 Sep 2000 13:25:03 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23332 for ; Sun, 3 Sep 2000 13:25:01 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id NAA07758; Sun, 3 Sep 2000 13:23:45 -0700 Date: Sun, 3 Sep 2000 13:23:45 -0700 Message-Id: <200009032023.NAA07758@finney.org> To: cme@acm.org, ietf-openpgp@imc.org Subject: Re: web page on Web of Trust Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 key-name bindings. (The new meta-introducer signatures do show trust, but they came later.) Broadly, we can say that there is an element of trust because we have to trust other people if we are going to rely on their certifications of key-name bindings. We could also say that we are asking whether we can trust a given key to be useful for a given purpose, such as encrypting email to a particular addresss. So a web of trust is a decentralized, non-hierarchical, cross-connected network useful in making decisions relating to trust, and in our case specifically to cryptographic trust in the sense above. (BTW epinions.com, an online product review service, has also adopted the term "web of trust" to refer to an eBay-like reputation system. http://www.epinions.com/help/index.html?show=web_of_trust.) This definition does seem to include SPKI. Even though the question being answered by SPKI is not the same as that for PGP, the mechanism has many similarities. Users utilize their keys to issue certificates which point at other keys. The set of all certificates, considered as pointers in this way, forms a web much as in the case of PGP. And the question, in the end, is whether a given key is useful for a given purpose, can it be trusted to be used for that purpose. So the web is used to make trust decisions. As I understand it (which may not be 100% correct), SPKI is even more of a web of trust than traditional PGP, because it allows for explicit delegation of certification power (similar to the PGP meta-introducers). When you issue a cert with the delegation bit set, you are trusting the receiver to delegate that power appropriately. Furthermore, this trust propagates through the web as his delegatees may make delegations of their own. In my opinion, any decentralized trust management system, whether PGP, SPKI, or the various research trust models like AT&T's KeyNote and PolicyMaker, can all be considered to implement a web of trust. The important element is the lack of a centralized hierarchy which is imposed on the trust decisions. (Of course webs of trust can usually support hierarchical trust models as a special case.) The biggest difference between SPKI and PGP is that SPKI is primarily oriented towards authorization certificates (is this cert holder allowed to use this resource?) while PGP is oriented towards identity and authentication certificates (who is this cert holder?). I'm not sure how the SDSI aspect fits into SPKI; the way you have described it, SDSI names sound so completely idiosyncratic as to be almost useless, and I'm not sure what question they answer. Hal From owner-ietf-openpgp@mail.imc.org Sun Sep 3 17:06:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12076 for ; Sun, 3 Sep 2000 17:06:26 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA23616 for ietf-openpgp-bks; Sun, 3 Sep 2000 13:50:23 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23612 for ; Sun, 3 Sep 2000 13:50:22 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id NAA07806; Sun, 3 Sep 2000 13:49:20 -0700 Date: Sun, 3 Sep 2000 13:49:20 -0700 Message-Id: <200009032049.NAA07806@finney.org> To: cme@acm.org, ietf-openpgp@imc.org Subject: Re: web page on Web of Trust Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 and trust, and we need to retain the essential attributes if we want to move these interactions into the electronic realm. In this view, the problem PGP tries to solve, which is to bind names to keys, is logically distinct and separate from the problem of an attribute based certification structure like SPKI. PGP provides an identity certification structure. It doesn't try to do more than that. You could then add a new and separate cert structure designed to handle other kinds of attributes. The identities can now be used as building blocks in this new cert structure; you can think of the new structure as either name-centric or key-centric, because both are now equivalent. It is especially attractive to see the identity PKI as existing solely to facilitate the use of the attribute PKI. Its only job, in this perspective, is to provide the name-key bindings that allow the attribute PKI to use names and keys interchangeably. In practice, this is not quite right, because the name-key binding that PGP provides does have utility in its own right, namely in helping users determine that messages were signed by certain people, or in finding keys to allow them to securely encrypt messages to their friends. But if we ignore these uses then we have the identity PKI solving a problem which is not very interesting (name-key binding) but one which adds convenience and intuitive depth to the attribute PKI. It is true that in setting up the identity PKI, you do have some structural similarities to the attribute PKI. If John is trusted to issue identity certificates, maybe he is also trusted to issue good-credit-risk certifications. These tasks look rather similar. But I argue that this is misleading; from the perspective above, the identity certification is useless in itself, and is only there to be one of the paving stones on which the attribute certification, which is the interesting one, is built. John's role in issuing identity certs is a rather sterile and formal one, merely binding names to keys, saying who owns what keys. Statements like these don't in themselves have any operational influence on the real world. It is when he and others start making substantive statements about the keys and their holders, statements about what they can and cannot do, or what they are like, or what their proclivities are, that we have some meat on our PKI and we can start doing useful stuff with it, like ecommerce and delegation of authority and granting various powers and privileges. Names are just labels, and the identity PKI is there solely to give us the ability to use names when we are ready to do real work with the attribute PKI. In short I see the task of the identity PKI as fundamentally different from the attribute PKI. Hal From owner-ietf-openpgp@mail.imc.org Wed Sep 6 00:27:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21480 for ; Wed, 6 Sep 2000 00:27:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA27438 for ietf-openpgp-bks; Tue, 5 Sep 2000 21:08:19 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA27430 for ; Tue, 5 Sep 2000 21:08:16 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A6AA51800234; Wed, 06 Sep 2000 12:10:34 0800 Message-Id: <4.3.2.7.0.20000906114132.00ba46a8@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Sep 2000 11:56:22 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: S2K and Tag 0x05 Q Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Wed Sep 6 01:12:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22569 for ; Wed, 6 Sep 2000 01:12:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA29286 for ietf-openpgp-bks; Tue, 5 Sep 2000 21:55:05 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA29280 for ; Tue, 5 Sep 2000 21:55:04 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id VAA13313; Tue, 5 Sep 2000 21:54:04 -0700 Date: Tue, 5 Sep 2000 21:54:04 -0700 Message-Id: <200009060454.VAA13313@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: S2K and Tag 0x05 Q Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 From owner-ietf-openpgp@mail.imc.org Wed Sep 6 01:34:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24827 for ; Wed, 6 Sep 2000 01:34:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA00142 for ietf-openpgp-bks; Tue, 5 Sep 2000 22:13:08 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA00134 for ; Tue, 5 Sep 2000 22:13:05 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A5E33345023A; Wed, 06 Sep 2000 13:15:31 0800 Message-Id: <4.3.2.7.0.20000906125625.00b63f28@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Sep 2000 13:01:19 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: S2K and Tag 0x05 Q Cc: hal@finney.org In-Reply-To: <200009060454.VAA13313@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 09:54 PM 5/09/2000 -0700, hal@finney.org wrote: > > 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 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Wed Sep 20 21:37:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13587 for ; Wed, 20 Sep 2000 21:37:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA11576 for ietf-openpgp-bks; Wed, 20 Sep 2000 18:05:51 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11571 for ; Wed, 20 Sep 2000 18:05:50 -0700 (PDT) Received: from whgiii.geiger.local (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id VAA32563 for ; Wed, 20 Sep 2000 21:08:35 -0400 Message-Id: <200009210108.VAA32563@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 20 Sep 2000 20:10:08 -0400 To: ietf-openpgp@imc.org Subject: OT Qualcomm bouncing attachments X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.2a/20 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 --------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Wed Sep 20 22:51:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15360 for ; Wed, 20 Sep 2000 22:51:38 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA12807 for ietf-openpgp-bks; Wed, 20 Sep 2000 19:22:45 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12803 for ; Wed, 20 Sep 2000 19:22:42 -0700 (PDT) Received: from [172.20.1.38] (64.0.151.21) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1) for ; Wed, 20 Sep 2000 19:25:25 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Wed, 20 Sep 2000 19:06:41 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: New draft... Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 From owner-ietf-openpgp@mail.imc.org Thu Sep 21 04:05:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01181 for ; Thu, 21 Sep 2000 04:05:38 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA18317 for ietf-openpgp-bks; Thu, 21 Sep 2000 00:48:30 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18311 for ; Thu, 21 Sep 2000 00:48:27 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13c1JT-0006JI-00; Thu, 21 Sep 2000 10:02:35 +0200 Date: Thu, 21 Sep 2000 10:02:34 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: New draft... Message-ID: <20000921100234.G24197@djebel.openit.de> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.8i In-Reply-To: ; from jon@callas.org on Wed, Sep 20, 2000 at 07:06:41PM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 From owner-ietf-openpgp@mail.imc.org Thu Sep 21 05:10:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01643 for ; Thu, 21 Sep 2000 05:10:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA20616 for ietf-openpgp-bks; Thu, 21 Sep 2000 01:50:25 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA20611 for ; Thu, 21 Sep 2000 01:50:22 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AFAD1591019E; Thu, 21 Sep 2000 16:54:21 0800 Message-Id: <4.3.2.7.0.20000921164743.00b93450@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Sep 2000 16:48:50 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: New draft... Cc: Jon Callas In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon, At 07:06 PM 20/09/2000 -0700, Jon Callas wrote: 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@comasp.com From owner-ietf-openpgp@mail.imc.org Fri Sep 29 07:38:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26915 for ; Fri, 29 Sep 2000 07:38:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA18989 for ietf-openpgp-bks; Fri, 29 Sep 2000 03:57:34 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA18981 for ; Fri, 29 Sep 2000 03:57:32 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26175; Fri, 29 Sep 2000 07:01:03 -0400 (EDT) Message-Id: <200009291101.HAA26175@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openpgp@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Date: Fri, 29 Sep 2000 07:01:02 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF. Title : OpenPGP Message Format Author(s) : J. Callas, L. Donnerhacke, H. Finney, R. Thayer Filename : draft-ietf-openpgp-rfc2440bis-01.txt Pages : 63 Date : 28-Sep-00 This document defines many tag values, yet it doesn't describe a mechanism for adding new tags (for new features). Traditionally the Internet Assigned Numbers Authority (IANA) handles the allocation of new values for future expansion and RFCs usually define the procedure to be used by the IANA. However there are subtle (and not so subtle) interactions that may occur in this protocol between new features and existing features which result in a significant reduction in over all security. Therefore this document does not define an extension procedure. Instead requests to define new tag values (say for new encryption algorithms for example) should be forwarded to the IESG Security Area Directors for consideration or forwarding to the appropriate IETF Working Group for consideration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-openpgp-rfc2440bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000928115139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-rfc2440bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000928115139.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openpgp@mail.imc.org Fri Sep 29 08:36:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28107 for ; Fri, 29 Sep 2000 08:36:38 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA22626 for ietf-openpgp-bks; Fri, 29 Sep 2000 04:59:15 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA22620 for ; Fri, 29 Sep 2000 04:59:13 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13ez4x-0000ij-00; Fri, 29 Sep 2000 14:15:51 +0200 Date: Fri, 29 Sep 2000 14:15:51 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Message-ID: <20000929141551.D2592@djebel.openit.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200009291101.HAA26175@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.8i In-Reply-To: <200009291101.HAA26175@ietf.org>; from Internet-Drafts@ietf.org on Fri, Sep 29, 2000 at 07:01:02AM -0400 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi! Thanks for updating the draft Jon. I think we should add the section on the new MDC packets. Those are implemented in PGP 7 and GnuPG 1.0.3. Hal: Can you post this proposed section again? Assuming that AES will be announced quite soon, we could issue a new draft right after this event. Ciao, Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Fri Sep 29 20:50:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08774 for ; Fri, 29 Sep 2000 20:50:15 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA15062 for ietf-openpgp-bks; Fri, 29 Sep 2000 17:19:49 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA15057 for ; Fri, 29 Sep 2000 17:19:48 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA16941 for ; Fri, 29 Sep 2000 17:23:08 -0700 (PDT) Received: from [64.0.151.23] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA16929 for ; Fri, 29 Sep 2000 17:23:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Fri, 29 Sep 2000 17:23:05 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: AES winner to be announced Monday. Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >Date: Fri, 29 Sep 2000 14:39:14 -0400 >Reply-To: cypherpunks@openpgp.net >Originator: cypherpunks@openpgp.net >From: "Trei, Peter" >To: Multiple recipients of list >Old-Subject: AES winner to be announced Monday. >X-Comment: All list traffic is being monitored by the FEDS!! >X-Toad: Yes >MIME-Version: 1.0 >X-Loop: openpgp.net >Subject: AES winner to be announced Monday. >Sender: owner-cypherpunks@minder.net >Precedence: bulk > >I can't get the web page myself, but the appended message >is in sci.crypt today: > >Peter Trei >------------------------ >X-Loop: openpgp.net >From: Jim Gillogly >1:03 PM > > Subject: Re: Deadline for AES... > >Tim Tyler wrote: >> No official announcement of the date has been posted yet on >> http://csrc.nist.gov/encryption/aes/ > >The new notice just went up at this site: announcement to be made >2 Oct with simultaneous webcast. They (explicitly) won't say yet >how many algorithms have been chosen as the AES. There's no mention >of new versions of SHA-* with appropriately longer hashes. >-- > Jim Gillogly > Sterday, 8 Winterfilth S.R. 2000, 17:00 > 12.19.7.10.12, 8 Eb 15 Chen, Fifth Lord of Night Received: by ns.secondary.com (8.9.3/8.9.3) id RAA15062 for ietf-openpgp-bks; Fri, 29 Sep 2000 17:19:49 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA15057 for ; Fri, 29 Sep 2000 17:19:48 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA16941 for ; Fri, 29 Sep 2000 17:23:08 -0700 (PDT) Received: from [64.0.151.23] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA16929 for ; Fri, 29 Sep 2000 17:23:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Fri, 29 Sep 2000 17:23:05 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: AES winner to be announced Monday. Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >Date: Fri, 29 Sep 2000 14:39:14 -0400 >Reply-To: cypherpunks@openpgp.net >Originator: cypherpunks@openpgp.net >From: "Trei, Peter" >To: Multiple recipients of list >Old-Subject: AES winner to be announced Monday. >X-Comment: All list traffic is being monitored by the FEDS!! >X-Toad: Yes >MIME-Version: 1.0 >X-Loop: openpgp.net >Subject: AES winner to be announced Monday. >Sender: owner-cypherpunks@minder.net >Precedence: bulk > >I can't get the web page myself, but the appended message >is in sci.crypt today: > >Peter Trei >------------------------ >X-Loop: openpgp.net >From: Jim Gillogly >1:03 PM > > Subject: Re: Deadline for AES... > >Tim Tyler wrote: >> No official announcement of the date has been posted yet on >> http://csrc.nist.gov/encryption/aes/ > >The new notice just went up at this site: announcement to be made >2 Oct with simultaneous webcast. They (explicitly) won't say yet >how many algorithms have been chosen as the AES. There's no mention >of new versions of SHA-* with appropriately longer hashes. >-- > Jim Gillogly > Sterday, 8 Winterfilth S.R. 2000, 17:00 > 12.19.7.10.12, 8 Eb 15 Chen, Fifth Lord of Night Received: by ns.secondary.com (8.9.3/8.9.3) id EAA22626 for ietf-openpgp-bks; Fri, 29 Sep 2000 04:59:15 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA22620 for ; Fri, 29 Sep 2000 04:59:13 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13ez4x-0000ij-00; Fri, 29 Sep 2000 14:15:51 +0200 Date: Fri, 29 Sep 2000 14:15:51 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Message-ID: <20000929141551.D2592@djebel.openit.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200009291101.HAA26175@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.8i In-Reply-To: <200009291101.HAA26175@ietf.org>; from Internet-Drafts@ietf.org on Fri, Sep 29, 2000 at 07:01:02AM -0400 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi! Thanks for updating the draft Jon. I think we should add the section on the new MDC packets. Those are implemented in PGP 7 and GnuPG 1.0.3. Hal: Can you post this proposed section again? Assuming that AES will be announced quite soon, we could issue a new draft right after this event. Ciao, Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id DAA18989 for ietf-openpgp-bks; Fri, 29 Sep 2000 03:57:34 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA18981 for ; Fri, 29 Sep 2000 03:57:32 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26175; Fri, 29 Sep 2000 07:01:03 -0400 (EDT) Message-Id: <200009291101.HAA26175@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openpgp@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Date: Fri, 29 Sep 2000 07:01:02 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF. Title : OpenPGP Message Format Author(s) : J. Callas, L. Donnerhacke, H. Finney, R. Thayer Filename : draft-ietf-openpgp-rfc2440bis-01.txt Pages : 63 Date : 28-Sep-00 This document defines many tag values, yet it doesn't describe a mechanism for adding new tags (for new features). Traditionally the Internet Assigned Numbers Authority (IANA) handles the allocation of new values for future expansion and RFCs usually define the procedure to be used by the IANA. However there are subtle (and not so subtle) interactions that may occur in this protocol between new features and existing features which result in a significant reduction in over all security. Therefore this document does not define an extension procedure. Instead requests to define new tag values (say for new encryption algorithms for example) should be forwarded to the IESG Security Area Directors for consideration or forwarding to the appropriate IETF Working Group for consideration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-openpgp-rfc2440bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000928115139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-rfc2440bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000928115139.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id BAA20616 for ietf-openpgp-bks; Thu, 21 Sep 2000 01:50:25 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA20611 for ; Thu, 21 Sep 2000 01:50:22 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AFAD1591019E; Thu, 21 Sep 2000 16:54:21 0800 Message-Id: <4.3.2.7.0.20000921164743.00b93450@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Sep 2000 16:48:50 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: New draft... Cc: Jon Callas In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon, At 07:06 PM 20/09/2000 -0700, Jon Callas wrote: 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@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id AAA18317 for ietf-openpgp-bks; Thu, 21 Sep 2000 00:48:30 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18311 for ; Thu, 21 Sep 2000 00:48:27 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13c1JT-0006JI-00; Thu, 21 Sep 2000 10:02:35 +0200 Date: Thu, 21 Sep 2000 10:02:34 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: New draft... Message-ID: <20000921100234.G24197@djebel.openit.de> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.8i In-Reply-To: ; from jon@callas.org on Wed, Sep 20, 2000 at 07:06:41PM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA12807 for ietf-openpgp-bks; Wed, 20 Sep 2000 19:22:45 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12803 for ; Wed, 20 Sep 2000 19:22:42 -0700 (PDT) Received: from [172.20.1.38] (64.0.151.21) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1) for ; Wed, 20 Sep 2000 19:25:25 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Wed, 20 Sep 2000 19:06:41 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: New draft... Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA11576 for ietf-openpgp-bks; Wed, 20 Sep 2000 18:05:51 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11571 for ; Wed, 20 Sep 2000 18:05:50 -0700 (PDT) Received: from whgiii.geiger.local (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id VAA32563 for ; Wed, 20 Sep 2000 21:08:35 -0400 Message-Id: <200009210108.VAA32563@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 20 Sep 2000 20:10:08 -0400 To: ietf-openpgp@imc.org Subject: OT Qualcomm bouncing attachments X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.2a/20 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 --------------------------------------------------------------- Received: by ns.secondary.com (8.9.3/8.9.3) id WAA00142 for ietf-openpgp-bks; Tue, 5 Sep 2000 22:13:08 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA00134 for ; Tue, 5 Sep 2000 22:13:05 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A5E33345023A; Wed, 06 Sep 2000 13:15:31 0800 Message-Id: <4.3.2.7.0.20000906125625.00b63f28@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Sep 2000 13:01:19 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: S2K and Tag 0x05 Q Cc: hal@finney.org In-Reply-To: <200009060454.VAA13313@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 09:54 PM 5/09/2000 -0700, hal@finney.org wrote: > > 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 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id VAA29286 for ietf-openpgp-bks; Tue, 5 Sep 2000 21:55:05 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA29280 for ; Tue, 5 Sep 2000 21:55:04 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id VAA13313; Tue, 5 Sep 2000 21:54:04 -0700 Date: Tue, 5 Sep 2000 21:54:04 -0700 Message-Id: <200009060454.VAA13313@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: S2K and Tag 0x05 Q Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA27438 for ietf-openpgp-bks; Tue, 5 Sep 2000 21:08:19 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA27430 for ; Tue, 5 Sep 2000 21:08:16 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A6AA51800234; Wed, 06 Sep 2000 12:10:34 0800 Message-Id: <4.3.2.7.0.20000906114132.00ba46a8@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Sep 2000 11:56:22 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: S2K and Tag 0x05 Q Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA23616 for ietf-openpgp-bks; Sun, 3 Sep 2000 13:50:23 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23612 for ; Sun, 3 Sep 2000 13:50:22 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id NAA07806; Sun, 3 Sep 2000 13:49:20 -0700 Date: Sun, 3 Sep 2000 13:49:20 -0700 Message-Id: <200009032049.NAA07806@finney.org> To: cme@acm.org, ietf-openpgp@imc.org Subject: Re: web page on Web of Trust Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 and trust, and we need to retain the essential attributes if we want to move these interactions into the electronic realm. In this view, the problem PGP tries to solve, which is to bind names to keys, is logically distinct and separate from the problem of an attribute based certification structure like SPKI. PGP provides an identity certification structure. It doesn't try to do more than that. You could then add a new and separate cert structure designed to handle other kinds of attributes. The identities can now be used as building blocks in this new cert structure; you can think of the new structure as either name-centric or key-centric, because both are now equivalent. It is especially attractive to see the identity PKI as existing solely to facilitate the use of the attribute PKI. Its only job, in this perspective, is to provide the name-key bindings that allow the attribute PKI to use names and keys interchangeably. In practice, this is not quite right, because the name-key binding that PGP provides does have utility in its own right, namely in helping users determine that messages were signed by certain people, or in finding keys to allow them to securely encrypt messages to their friends. But if we ignore these uses then we have the identity PKI solving a problem which is not very interesting (name-key binding) but one which adds convenience and intuitive depth to the attribute PKI. It is true that in setting up the identity PKI, you do have some structural similarities to the attribute PKI. If John is trusted to issue identity certificates, maybe he is also trusted to issue good-credit-risk certifications. These tasks look rather similar. But I argue that this is misleading; from the perspective above, the identity certification is useless in itself, and is only there to be one of the paving stones on which the attribute certification, which is the interesting one, is built. John's role in issuing identity certs is a rather sterile and formal one, merely binding names to keys, saying who owns what keys. Statements like these don't in themselves have any operational influence on the real world. It is when he and others start making substantive statements about the keys and their holders, statements about what they can and cannot do, or what they are like, or what their proclivities are, that we have some meat on our PKI and we can start doing useful stuff with it, like ecommerce and delegation of authority and granting various powers and privileges. Names are just labels, and the identity PKI is there solely to give us the ability to use names when we are ready to do real work with the attribute PKI. In short I see the task of the identity PKI as fundamentally different from the attribute PKI. Hal Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA23337 for ietf-openpgp-bks; Sun, 3 Sep 2000 13:25:03 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23332 for ; Sun, 3 Sep 2000 13:25:01 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id NAA07758; Sun, 3 Sep 2000 13:23:45 -0700 Date: Sun, 3 Sep 2000 13:23:45 -0700 Message-Id: <200009032023.NAA07758@finney.org> To: cme@acm.org, ietf-openpgp@imc.org Subject: Re: web page on Web of Trust Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 key-name bindings. (The new meta-introducer signatures do show trust, but they came later.) Broadly, we can say that there is an element of trust because we have to trust other people if we are going to rely on their certifications of key-name bindings. We could also say that we are asking whether we can trust a given key to be useful for a given purpose, such as encrypting email to a particular addresss. So a web of trust is a decentralized, non-hierarchical, cross-connected network useful in making decisions relating to trust, and in our case specifically to cryptographic trust in the sense above. (BTW epinions.com, an online product review service, has also adopted the term "web of trust" to refer to an eBay-like reputation system. http://www.epinions.com/help/index.html?show=web_of_trust.) This definition does seem to include SPKI. Even though the question being answered by SPKI is not the same as that for PGP, the mechanism has many similarities. Users utilize their keys to issue certificates which point at other keys. The set of all certificates, considered as pointers in this way, forms a web much as in the case of PGP. And the question, in the end, is whether a given key is useful for a given purpose, can it be trusted to be used for that purpose. So the web is used to make trust decisions. As I understand it (which may not be 100% correct), SPKI is even more of a web of trust than traditional PGP, because it allows for explicit delegation of certification power (similar to the PGP meta-introducers). When you issue a cert with the delegation bit set, you are trusting the receiver to delegate that power appropriately. Furthermore, this trust propagates through the web as his delegatees may make delegations of their own. In my opinion, any decentralized trust management system, whether PGP, SPKI, or the various research trust models like AT&T's KeyNote and PolicyMaker, can all be considered to implement a web of trust. The important element is the lack of a centralized hierarchy which is imposed on the trust decisions. (Of course webs of trust can usually support hierarchical trust models as a special case.) The biggest difference between SPKI and PGP is that SPKI is primarily oriented towards authorization certificates (is this cert holder allowed to use this resource?) while PGP is oriented towards identity and authentication certificates (who is this cert holder?). I'm not sure how the SDSI aspect fits into SPKI; the way you have described it, SDSI names sound so completely idiosyncratic as to be almost useless, and I'm not sure what question they answer. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id TAA23019 for ietf-openpgp-bks; Sat, 2 Sep 2000 19:19:45 -0700 (PDT) Received: from mx.spiritone.com (mx.spiritone.com [205.139.108.5]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA23015 for ; Sat, 2 Sep 2000 19:19:43 -0700 (PDT) Received: (qmail 21356 invoked from network); 3 Sep 2000 02:21:01 -0000 Received: (ofmipd 208.130.241.164); 3 Sep 2000 02:20:39 -0000 Date: 2 Sep 2000 19:21:37 -0700 Message-Id: <3.0.5.32.20000902192137.008eed90@spiritone.com> From: "Carl Ellison" To: ietf-openpgp@imc.org X-Sender: cellison@spiritone.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Subject: web page on Web of Trust Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQA/AwUBObG1sHPxfjyW5ytxEQLT3wCguu1z6pdFKTtrmYwpR7iC/OZPoLQAoOfz 6AJbF4kqSf8vQeCD/5ToiES1 =64cc -----END PGP SIGNATURE----- +------------------------------------------------------------------+ |Carl M. Ellison cme@acm.org http://world.std.com/~cme | | PGP: 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 | +--Officer, officer, arrest that man. He's whistling a dirty song.-+