From owner-ietf-open-pgp Tue Jul 22 09:31:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA01050 for ietf-open-pgp-bks; Tue, 22 Jul 1997 09:31:42 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA01045 for ; Tue, 22 Jul 1997 09:31:38 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id JAA21560 for ; Tue, 22 Jul 1997 09:35:05 -0700 (PDT) Message-Id: <3.0.2.32.19970722093924.0097d770@mail.pgp.com> X-Sender: cbreed@mail.pgp.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 22 Jul 1997 09:39:24 -0700 To: ietf-open-pgp@imc.org From: Charles Breed Subject: IETF "Open-PGP" Birds of a Feather Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk IETF Munich, "Open-PGP" Birds of a Feather Meeting Notice --------------------------------------------------------- http://www.imc.org/ietf-open-pgp/ This is to confirm one session for OPEN-PGP BOF as follows: Tuesday, August 12 at 0900-1115 (opposite charset ipvbi, idr, rsvp, ssh 2000, calsch) Marcia ********************************************************************** Marcia Beaulieu IETF Meeting Coordinator Voice: 703-620-8990 ext. 210 Fax: 703-758-5913 From owner-ietf-open-pgp Wed Jul 23 12:15:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA05744 for ietf-open-pgp-bks; Wed, 23 Jul 1997 12:15:22 -0700 (PDT) Received: from mailhost.transarc.com (mailhost.transarc.com [158.98.16.250]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA05740 for ; Wed, 23 Jul 1997 12:15:18 -0700 (PDT) Received: from [158.98.7.94] (rilke.transarc.com [158.98.7.94]) by mailhost.transarc.com (8.8.0/8.8.0) with ESMTP id PAA19038 for ; Wed, 23 Jul 1997 15:18:33 -0400 (EDT) X-Sender: cox@mailhost.transarc.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Jul 1997 15:18:03 -0400 To: ietf-open-pgp@imc.org From: Ben Cox Subject: Key search Sender: owner-ietf-open-pgp@imc.org Precedence: bulk (Is this list "open for business" yet?) Hello all, I am interested in a key search mechanism by which I can ask a key server for a chain of keys which leads between a desired key and a key that I trust. For example, if I trust A's key, and I am interested in finding a chain by which I can trust D, I can ask the key server for the chain and it will return B and C (where A has signed B's key, B has signed C's key, and C has signed D's). I actually have code that will do this for a PGP 2.6 key ring, and am willing to contribute it to whomever is interested in it. Basically it builds a directed graph whose vertices are the keys and whose edges point from a key to all keys that have signed it. It then does a breadth-first search of the graph, starting at the requested key, stopping when it finds one of the keys listed as "trusted". When it finds a trusted key, it returns all the keys on the path from the starting vertex to the ending vertex. Is anyone interested in seeing this code? __ Ben Cox cox@transarc.com From owner-ietf-open-pgp Wed Jul 23 12:34:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA06132 for ietf-open-pgp-bks; Wed, 23 Jul 1997 12:34:26 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA06128 for ; Wed, 23 Jul 1997 12:34:20 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id MAA17493 for ; Wed, 23 Jul 1997 12:37:52 -0700 (PDT) Message-Id: <3.0.2.32.19970723124214.00aa1210@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 23 Jul 1997 12:42:14 -0700 To: ietf-open-pgp@imc.org From: Charles Breed Subject: Re: Key search In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hello Ben, You might want to check out http://akpublic.research.att.com/~reiter/PathServer/ written by Mike Reiter and Stuart Stubblebine This list will be used for discussing new features and functionality to be in the next, open, standards-track pgp spec, hopefully from the IETF working group called open-pgp. At 03:18 PM 7/23/97 -0400, you wrote: >(Is this list "open for business" yet?) > >Hello all, > >I am interested in a key search mechanism by which I can ask a >key server for a chain of keys which leads between a desired key >and a key that I trust. > >For example, if I trust A's key, and I am interested in finding >a chain by which I can trust D, I can ask the key server for the >chain and it will return B and C (where A has signed B's key, B >has signed C's key, and C has signed D's). > >I actually have code that will do this for a PGP 2.6 key ring, >and am willing to contribute it to whomever is interested in it. > >Basically it builds a directed graph whose vertices are the keys >and whose edges point from a key to all keys that have signed it. >It then does a breadth-first search of the graph, starting at the >requested key, stopping when it finds one of the keys listed as >"trusted". When it finds a trusted key, it returns all the keys >on the path from the starting vertex to the ending vertex. > >Is anyone interested in seeing this code? > > >__ >Ben Cox >cox@transarc.com > > > > From owner-ietf-open-pgp Wed Jul 23 12:47:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA06315 for ietf-open-pgp-bks; Wed, 23 Jul 1997 12:47:37 -0700 (PDT) Received: from procert.cert.dfn.de (root@procert.cert.dfn.de [134.100.14.1]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA06310 for ; Wed, 23 Jul 1997 12:47:33 -0700 (PDT) Received: from tiger.cert.dfn.de (ley@tiger.cert.dfn.de [134.100.14.11]) by procert.cert.dfn.de (8.8.5/8.8.5) with ESMTP id VAA28637; Wed, 23 Jul 1997 21:50:43 +0200 (MET DST) From: Wolfgang Ley Received: (from ley@localhost) by tiger.cert.dfn.de (8.8.5/8.8.5) id VAA10789; Wed, 23 Jul 1997 21:50:42 +0200 (MET DST) Message-Id: <199707231950.VAA10789@tiger.cert.dfn.de> Subject: Re: Key search To: cox+@transarc.com (Ben Cox) Date: Wed, 23 Jul 1997 21:50:41 +0200 (MET DST) Cc: ietf-open-pgp@imc.org In-Reply-To: from "Ben Cox" at Jul 23, 97 03:18:03 pm Organization: DFN-CERT (Computer Emergency Response Team, Germany) Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Ben Cox wrote: > > (Is this list "open for business" yet?) > > Hello all, > > I am interested in a key search mechanism by which I can ask a > key server for a chain of keys which leads between a desired key > and a key that I trust. > > For example, if I trust A's key, and I am interested in finding > a chain by which I can trust D, I can ask the key server for the > chain and it will return B and C (where A has signed B's key, B > has signed C's key, and C has signed D's). > > I actually have code that will do this for a PGP 2.6 key ring, > and am willing to contribute it to whomever is interested in it. > > Basically it builds a directed graph whose vertices are the keys > and whose edges point from a key to all keys that have signed it. > It then does a breadth-first search of the graph, starting at the > requested key, stopping when it finds one of the keys listed as > "trusted". When it finds a trusted key, it returns all the keys > on the path from the starting vertex to the ending vertex. > > Is anyone interested in seeing this code? Hi, I don't know why this should be useful. In real life this won't help you because if you trust A's key and want to find a path to D then the only way would be "A has signed D". In all other case you have to trust the keys on the path (in your example B and C) to act as an introducer. So the real life situation is most probably more like "get the key from D, add it to your keyring to check if you can verify with your existing keys/trust definitions". If you can't then have lost because the helper keys B and C are most probably from people you've never met in person before and therefor can't judge on their key management to use them as an introducer. On the other hand (if you're able to make that judge- ment) then you've met already and the other key is already inside your keyring to be sure that your trust judgement is really valid for that person and not just for a key with the name of person you met before. I think most "path finder" ideas do have several drawbacks + The only work on key signatures not on the trust levels + The programs I've seen are working on key->key->...->key paths and not on the needed key->key->...->key/userid paths (a signature is always valid for a key/userid combination, bot for the key only) By the way: a nice PathServer is available from AT&T - see http://www.research.att.com/~reiter/PathServer/ Bye, Wolfgang Ley (DFN-CERT) - -- Wolfgang Ley, DFN-CERT, Vogt-Koelln-Str. 30, 22527 Hamburg, Germany Email: ley@cert.dfn.de Phone: +49 40 5494-2262 Fax: +49 40 5494-2241 PGP-Key available via finger ley@ftp.cert.dfn.de any key-server or via WWW from http://www.cert.dfn.de/~ley/ ...have a nice day -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBM9ZgjgQmfXmOCknRAQFHkQQAnabPitydrXHRtJloiOOwrkHs6PWL0n8W aDNFtZl7giLqUVJfFPKnioJTAc10L5HYJISxMwwiJXYBwWlq6fqLTCKkZNoe1Pud ia0ZoG6TOUuqQx3lBLsiZ3Qo/Sa/mQ/zwfugETFF0dhPW8/Gh5ksEvXt/3XyWF20 rKNpAlX64B8= =uhzY -----END PGP SIGNATURE----- From owner-ietf-open-pgp Wed Jul 23 14:03:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA07334 for ietf-open-pgp-bks; Wed, 23 Jul 1997 14:03:18 -0700 (PDT) Received: from mailhost.transarc.com (mailhost.transarc.com [158.98.16.250]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA07330 for ; Wed, 23 Jul 1997 14:03:15 -0700 (PDT) Received: from [158.98.7.94] (rilke.transarc.com [158.98.7.94]) by mailhost.transarc.com (8.8.0/8.8.0) with ESMTP id RAA25163; Wed, 23 Jul 1997 17:05:41 -0400 (EDT) X-Sender: cox@mailhost.transarc.com Message-Id: In-Reply-To: <3.0.2.32.19970723124214.00aa1210@mail.pgp.com> References: Mime-Version: 1.0 Date: Wed, 23 Jul 1997 16:35:28 -0400 To: Charles Breed From: Ben Cox Subject: Re: Key search Cc: ietf-open-pgp@imc.org Content-Type: multipart/signed; boundary="PGPplugin/Eudora-5.0-42029812327-1342444942"; micalg=pgp-md5; protocol="application/pgp-signature";PGPFormat="PGPMIME-signed" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --PGPplugin/Eudora-5.0-42029812327-1342444942 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Charles Breed writes: >You might want to check out http://akpublic.research.att.com/~reiter/PathServer/ >written by Mike Reiter and Stuart Stubblebine Thanks; this looks very similar to what I have. >This list will be used for discussing new features and functionality to be >in the next, open, standards-track pgp spec, hopefully from the IETF >working group called open-pgp. ...and, to quote the charter: >- enhanced methods for public pgp key / certificate exchange > (search, retrieval, revocation) ^^^^^^^^^^^^^^^^^ Wolfgang Ley writes: >I don't know why this should be useful. In real life this won't help [...] >So the real life situation is most probably more like "get the key from >D, add it to your keyring to check if you can verify with your existing >keys/trust definitions". If you can't then have lost because the helper >keys B and C are most probably from people you've never met in person >before and therefor can't judge on their key management to use them >as an introducer. On the other hand (if you're able to make that judge- >ment) then you've met already and the other key is already inside your >keyring to be sure that your trust judgement is really valid for that >person and not just for a key with the name of person you met before. I beg to differ. Suppose I do the search for D given that I trust A and it gives me A->B->C->D, and persons B and C turn out to be, for example, Jeff Schiller and Phil Zimmermann. Now, I might never have met them before, and I might not have their keys on my keyring (ignore for the moment that those keys are on the keyring shipped with PGP), but I know them by reputation. If I can believe person A that the holder of key B really _is_ Jeff Schiller, then I should be able to believe Jeff Schiller that the holder of key C really _is_ Phil Zimmermann, and thus I should be able to believe that person D is who Phil says he is. I think the path finder idea is quite useful. It may be that the results I get from doing the path search don't necessarily work to directly establish the link to D (i.e., D shouldn't automatically become completely valid immediately with no further interaction by me), but I may be able to retrieve some useful keys that I can then go and manipulate by hand (i.e., adjust the trust levels). >I think most "path finder" ideas do have several drawbacks >+ The only work on key signatures not on the trust levels Again, I think the path finder can be a good first step, working on the signatures and giving me the raw materials to manipulate the trust levels by hand based on knowledge that cannot be represented in the PGP keyring itself. >+ The programs I've seen are working on key->key->...->key paths and not > on the needed key->key->...->key/userid paths (a signature is always > valid for a key/userid combination, bot for the key only) Yes; I suppose it would be fairly easy to modify my code to take a key ID and a userid as input, and only return paths that lead to the correct userid. (Right now it returns paths that lead to any userid on the specified key.) Cheers, __ Ben Cox cox@transarc.com --PGPplugin/Eudora-5.0-42029812327-1342444942 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0 for non-commercial use MessageID: +LsqXj+lFR7EklV1JjlYpzqfXoGUeIgQ iQB1AwUBM9ZyMcG2F+gi/gIZAQHppQL8DLwPuKCKHjAqN02nW9HadPhgGFU5epaP wdf9rlkhvaCbnfwq59p/GrrRc8jbyAq4b57sPkNktZRDj+nA7l5PBG4PvSkmHT5I hreW+lhH6xfNSXEar7potfHSaLTHsE00 =r6lw -----END PGP SIGNATURE----- --PGPplugin/Eudora-5.0-42029812327-1342444942-- From owner-ietf-open-pgp Wed Jul 23 14:32:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA07771 for ietf-open-pgp-bks; Wed, 23 Jul 1997 14:32:30 -0700 (PDT) Received: from netcom17.netcom.com (root@netcom17.netcom.com [192.100.81.130]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA07761 for ; Wed, 23 Jul 1997 14:32:24 -0700 (PDT) Received: from [10.0.2.15] (azur@localhost.netcom.com [127.0.0.1]) by netcom17.netcom.com (8.6.13/Netcom) id OAA15891; Wed, 23 Jul 1997 14:35:46 -0700 X-Sender: azur@localhost Message-Id: In-Reply-To: <199707231950.VAA10789@tiger.cert.dfn.de> References: from "Ben Cox" at Jul 23, 97 03:18:03 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Jul 1997 14:31:04 -0700 To: Wolfgang Ley , ietf-open-pgp@imc.org From: Steve Schear Subject: Re: Key search Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Wolfgang Ley , wrote: >I don't know why this should be useful. In real life this won't help >you because if you trust A's key and want to find a path to D then >the only way would be "A has signed D". In all other case you have >to trust the keys on the path (in your example B and C) to act as an >introducer. Phil mentioned, at the June 14th Cypherpunks meeting, that an upcoming version of PGP will support introducers. --Steve From owner-ietf-open-pgp Wed Jul 23 14:32:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA07758 for ietf-open-pgp-bks; Wed, 23 Jul 1997 14:32:15 -0700 (PDT) Received: from netcom17.netcom.com (root@netcom17.netcom.com [192.100.81.130]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA07754 for ; Wed, 23 Jul 1997 14:32:11 -0700 (PDT) Received: from [10.0.2.15] (azur@localhost.netcom.com [127.0.0.1]) by netcom17.netcom.com (8.6.13/Netcom) id OAA15869; Wed, 23 Jul 1997 14:35:38 -0700 X-Sender: azur@localhost Message-Id: In-Reply-To: <3.0.2.32.19970723124214.00aa1210@mail.pgp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Jul 1997 14:27:25 -0700 To: ietf-open-pgp@imc.org From: Steve Schear Subject: Subject line Sender: owner-ietf-open-pgp@imc.org Precedence: bulk It is obvious that descriptive email Subject lines can offer a potential security leak, aiding traffic analysis and eavesdropping. Therefore cautious crypto emailers either leave this line blank, use a non-descriptive header line, etc. Might it be possible to add a feature to the PGP cyphertext body so email plug-ins could save the Subject line in the cyphertext, blank the email field during transit and restore its value after decryption at the receiptient end? --Steve From owner-ietf-open-pgp Wed Jul 23 15:13:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA08325 for ietf-open-pgp-bks; Wed, 23 Jul 1997 15:13:53 -0700 (PDT) Received: from mailhub.amaranth.com (root@mailhub.amaranth.com [209.37.228.4]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA08321 for ; Wed, 23 Jul 1997 15:13:49 -0700 (PDT) Received: from mailhub.amaranth.com (ppp28.pensacola.com [209.37.228.28]) by mailhub.amaranth.com (8.8.5/8.8.5) with SMTP id RAA28465; Wed, 23 Jul 1997 17:05:55 -0500 Message-Id: <199707232205.RAA28465@mailhub.amaranth.com> From: "William H. Geiger III" Reply-to: "William H. Geiger III" Date: Wed, 23 Jul 97 16:53:56 -0400 To: Steve Schear In-Reply-To: Cc: ietf-open-pgp@imc.org Subject: Re: Subject line X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.30 b29 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In , on 07/23/97 at 04:27 PM, Steve Schear said: >It is obvious that descriptive email Subject lines can offer a potential >security leak, aiding traffic analysis and eavesdropping. Therefore >cautious crypto emailers either leave this line blank, use a >non-descriptive header line, etc. >Might it be possible to add a feature to the PGP cyphertext body so email >plug-ins could save the Subject line in the cyphertext, blank the email >field during transit and restore its value after decryption at the >receiptient end? This can be doen quite easily by the client software as follows: Create message sign message encrypt message with final recipiant's public key Create new message where old message is a multipart/encrypted attachment. [New Header multipart/mixed] [message/rfc822] [application/pgp-encrypted] [application/octet-stream] The only information in the header of the new message is that which is need to deliver the message. After this new message has been created one does the proper encryption wrapping for the remailer chain. IMHO this all should be handled on the client end and really shouldn't involve PGP at all. - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBM9Zy149Co1n+aLhhAQE/dAP/bBqmbtqANkxOf4JooXlqpOJEliGCrgzs z2hnIPkKeeEf5DOTDMsyErS2KWQJG1+IuqmCOCR4fHbcv0dWaX7BwFo44XBz4z8O NnpBKQ7EuhlxTjst+01JhT9INHSswucEwRE1e3eDLikX61aYnmzLC9COmSDuP8PZ m0ttAAMiij0= =0tWr -----END PGP SIGNATURE----- From owner-ietf-open-pgp Wed Jul 23 15:16:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA08369 for ietf-open-pgp-bks; Wed, 23 Jul 1997 15:16:23 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA08365 for ; Wed, 23 Jul 1997 15:16:20 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id PAA22296 for ; Wed, 23 Jul 1997 15:19:51 -0700 (PDT) Message-Id: <3.0.2.32.19970723152413.00b225b0@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 23 Jul 1997 15:24:13 -0700 To: ietf-open-pgp@imc.org From: Charles Breed Subject: Re: Subject line In-Reply-To: References: <3.0.2.32.19970723124214.00aa1210@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Steve, Encryption of SUBJECT LINES: can be useful, this was discussed on the PGP/MIME mail list. To the best of my knowledge, there was no definitive conclusion. I'll keep track of these requests. MUA should allow user's to sort mail and view subject lines without requiring decryption, or automating the process. User's should be smart enough not to make subject_lines too descriptive, however, any subject adds to traffic analysis. cb At 02:27 PM 7/23/97 -0700, Steve Schear wrote: >It is obvious that descriptive email Subject lines can offer a potential >security leak, aiding traffic analysis and eavesdropping. Therefore >cautious crypto emailers either leave this line blank, use a >non-descriptive header line, etc. > >Might it be possible to add a feature to the PGP cyphertext body so email >plug-ins could save the Subject line in the cyphertext, blank the email >field during transit and restore its value after decryption at the >receiptient end? > >--Steve > > > > From owner-ietf-open-pgp Fri Jul 25 07:09:02 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA07447 for ietf-open-pgp-bks; Fri, 25 Jul 1997 07:09:02 -0700 (PDT) Received: from mawar.singnet.com.sg (mawar.singnet.com.sg [165.21.1.19]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA07443 for ; Fri, 25 Jul 1997 07:08:58 -0700 (PDT) Received: from ts900-12008.singnet.com.sg (ts900-8703.singnet.com.sg [165.21.169.55]) by mawar.singnet.com.sg (8.8.5/8.8.5) with SMTP id WAA07017 for ; Fri, 25 Jul 1997 22:12:31 +0800 (SST) Received: by ts900-12008.singnet.com.sg with Microsoft Mail id <01BC9948.BB823920@ts900-12008.singnet.com.sg>; Fri, 25 Jul 1997 22:18:52 +0800 Message-ID: <01BC9948.BB823920@ts900-12008.singnet.com.sg> From: Tay Beng Kuan Steven To: "'ietf-open-pgp@imc.org'" Subject: digest mode Date: Fri, 25 Jul 1997 22:16:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hi all, How do I receive in digest mode. -------- Tay Beng Kuan Steven [ ICQ: 1423100 ] Url : Http://web.singnet.com.sg/~taylc/ Email : taylc@mbox2.singnet.com.sg / bkuan@post1.com PGP Key-ID 4036268D Send message to me with subject "send pgp" for key Key fingerprint = 65 6F 50 EB 09 7B C7 83 96 7C F9 82 5F E5 5F F6 From owner-ietf-open-pgp Wed Jul 30 16:58:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA04449 for ietf-open-pgp-bks; Wed, 30 Jul 1997 16:58:44 -0700 (PDT) Received: from peace.netris.org (peace.netris.org [205.180.136.234]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA04445 for ; Wed, 30 Jul 1997 16:58:38 -0700 (PDT) Received: (qmail 11140 invoked by uid 1001); 31 Jul 1997 00:02:35 -0000 Message-ID: <19970731000235.11138.qmail@peace.netris.org> X-PGP-DSS-Key: http://keys.pgp.com:11371/pks/lookup?op=get&search=0xACCCA305 From: jude shabry To: internet-drafts@ietf.org, ietf-open-pgp@imc.org Subject: PGP Message Exchange Formats Internet Draft Reply-to: jude shabry Date: Wed, 30 Jul 1997 17:02:34 -0700 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk INTERNET-DRAFT Gail Haspert Security PGP, Inc. Expires in six months Editor July 30 1997 PGP Message Exchange Formats Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). In order to release information about PGP 5.x prior to the Birds of a Feather discussion at the 39th IETF Conference in Munich, we wanted people to have the opportunity to review the current specification of the published PGP source code. This document is the cookbook for the source code. Completion of items marked TBD will be done by end of October, 1997. Abstract PGP (Pretty Good Privacy) software uses a combination of public-key and conventional encryption to provide strong security services for e-mail, EDI, and data files. These services include confidentiality, authorization, authentication and digital signature. This document specifies the message formats used in version 5.x, fully backward- compatible with earlier PGP versions. Since PGP first became available in 1991, it is now the worldwide de facto standard for securing electronic communications. It has achieve this success through international availability and the unique distributed "Web-of-Trust" model to create the current PGP Public Key Infrastructure for storing and obtaining 'PGP-formatted-certificates.' PGP Formats - Open PGP BOF Page 1 Table of Contents 1. Introduction......................................3 2. PGP Services......................................3 2.1 Digital signature.................................3 2.2 Confidentiality...................................4 2.3 Compression.......................................4 2.4 Radix-64 conversion...............................4 2.4.1 ASCII Armor Formats...............................5 3. Data Element Formats..............................6 3.1 Scalar numbers....................................6 3.2 Multi-Precision Integers..........................6 3.3 Strings...........................................7 3.4 Time fields.......................................7 4. Packets...........................................7 4.1 Overview..........................................7 4.2 Packet Headers....................................7 4.3 Packet Tags.......................................8 5. Packet Types......................................9 5.1 Encrypted Session Key Packets.....................9 5.2 Conventional Encrypted Session-Key Packets........9 5.3 One-Pass Signature Packets........................9 5.4 Symmetrically Encrypted Data Packet..............10 5.5 Compressed Data Packet...........................10 5.6 Literal Data Packet..............................10 5.7 Obsolete Literal Packet..........................11 5.8 Key Material Packet..............................11 5.9 User-Name Packet.................................12 5.10 Signature Packets................................12 6. Constants........................................13 6.1 Public Key Algorithms............................13 6.2 Symmetric Key Algorithms.........................13 6.3 Compression Algorithms...........................13 6.4 Hash Algorithms..................................13 7. Transferable Public Keys.........................13 8. PGP 5.0 Enhanced Key Formats.....................14 8.1 Key Structures...................................14 8.2 Public Key Certificate Packet Structure..........15 8.3 Signature Packet Structure.......................16 8.4 Diffie-Hellman/DSS Key IDs and Fingerprints......18 8.5 New Algorithm and Signature Classification Types.18 8.6 Interoperability.................................18 8.7 Future Formats...................................19 PGP Formats - Open PGP BOF Page 2 1. Introduction This document provides information on the message-exchange packet formats used by PGP to provide encryption, decryption, and signing functions. It builds on the foundation provided RFC 1991, PGP Message Exchange Formats and RFC 2015, MIME Security with Pretty Good Privacy (PGP). PGP and is the collective work of a number of contributing authors. Those authors include, (alphabetical order): Derek Atkins, Charles Breed, Jon Callas, Dave Del Torto, Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Raph Levine, Colin Plumb, Will Price, William Stallings, Mark Weaver, and Philip R. Zimmermann. A special thank you goes to Paul Hoffman for hosting and managing the mail lists for PGP.PGP (Pretty Good Privacy) uses a combination of public-key and conventional encryption to provide security services for electronic mail messages, electronic data interchange (EDI) and data files. These services include confidentiality and digital signature. PGP is widely used throughout the global computer community. This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed 1991. Subsequent versions have been designed and implemented by a combination of volunteers and PGP, Inc. in a collaborative effort under the design guidance of Philip Zimmermann. PGP and Pretty Good Privacy are trademarks of Pretty Good Privacy, Inc. 2. PGP Services PGP provides four services related to the format of messages and data files: -digital signature -encryption -compression -radix-64 conversion 2.1 Digital signature The digital signature uses a hash code or message digest algorithm, and a public-key encryption algorithm. The sequence is as follows: 1. The sender creates a message 2. The sending PGP generates a hash code of the message 3. The sending PGP encrypts the hash code using the sender's private key. 4. The encrypted hash code is prepended to the message 5. The receiving PGP decrypts the hash code using the sender's public key. 6. The receiving PGP generates a new hash code for the received message and compares it to the decrypted hash code. If the two match, the message is accepted as authentic. PGP Formats - Open PGP BOF Page 3 2.2 Confidentiality PGP provides confidentiality by encrypting messages to be transmitted or data files to be stored locally using conventional encryption. In PGP, each conventional key is used only once. That is, a new key is generated as a random 128-bit number for each message. Since it is to be used only once, the session key is bound to the message and transmitted with it. To protect the key, it is encrypted with the receiver's public key. The sequence is as follows: 1. The sender creates a message. 2. The sending PGP generates a random number to be used as a session key for this message only. 3. The sending PGP encrypts the message using the session key. 4. The session key is encrypted using the recipient's public key and is prepended to the encrypted message. 5. The receiving PGP decrypts the session key using the recipient's private key. 6. The receiving PGP decrypts the message using the session key. Both digital signature and confidentiality services may be applied to the same message. First, a signature is generated for the message and prepended to the message. Then, the message plus signature is encrypted using a conventional session key. Finally, the session key is encrypted using public-key encryption and prepended to the encrypted block. 2.3 Compression As a default, PGP compresses the message after applying the signature but before encryption. 2.4 Radix-64 conversion When using PGP to sign clear text, or to encrypt and/or sign a message a resulting encrypted block must either accompany or travel in place of the message block. Thus, part or all of the resulting block consists of a stream of arbitrary octets. Many electronic mail systems only permit the use of blocks consisting of ASCII text. To accommodate this restriction, PGP provides the service of converting the raw 8-bit binary octet stream to a stream of printable ASCII characters, called Radix-64 encoding or ASCII Armor. Similar to MIME encoding, the process of Radix-64 encoding an 8-bit binary stream of data is as follows. Every three subsequent 8 bit binary octets are mapped into four subsequent 6-bit ASCII characters. Radix-64 encoding also appends a CRC to detect transmission errors. This radix-64 conversion, is a wrapper around the binary PGP messages, and is used to protect the binary messages during transmission over non-binary channels, such as Internet Email. The following table defines the mapping. The characters used are the upper- and lower-case letters, the digits 0 through 9, and the characters + and /. The carriage-return and linefeed characters aren't used in the conversion, nor is the tab or any other character that might be altered by the mail system. The result is a text file that is "immune" to the modifications inflicted by mail systems. PGP Formats - Open PGP BOF Page 4 To encode an arbitrary 3 octets, separate the bit stream logically into four 6-bit groups, calculate the decimal value of the 6-bit group, and replace it with the corresponding character from the table below. Decoding is the exact opposite operation. 6-bit Value Mapped to Character Encoding 6-bit character 6-bit character 6-bit character 6-bit character value encoding value encoding value encoding value encoding 0 A 16 Q 32 g 48 w 1 B 17 R 33 h 49 x 2 C 18 S 34 i 50 y 3 D 19 T 35 j 51 z 4 E 20 U 36 k 52 0 5 F 21 V 37 l 53 1 6 G 22 W 38 m 54 2 7 H 23 X 39 n 55 3 8 I 24 Y 40 o 56 4 9 J 25 Z 41 p 57 5 1 K 26 a 42 q 58 6 11 L 27 b 43 r 59 7 12 M 28 c 44 s 60 8 13 N 29 d 45 t 61 9 14 O 30 e 46 u 62 + 15 P 31 f 47 v 63 / (pad) = Hex octet 0x17 0x3A 0xA3 Example: Binary stream 00010111 00111010 10100011 Translate to 6bit 000101 110011 101010 100011 Decimal 5 51 42 35 Final Character F z q j It is possible to use PGP to convert any arbitrary file to ASCII Armor. When this is done, PGP tries to compress the data before it is converted to Radix-64. 2.4.1 ASCII Armor Formats When PGP encodes data into ASCII Armor, it puts specific headers around the data, so PGP can reconstruct the data at a future time. PGP tries to inform the user what kind of data is encoded in the ASCII armor through the use of the headers. ASCII Armor is created by concatenating the following data: - An Armor Headerline, appropriate for the type of data - Armor Headers - A blank line - The ASCII-Armored data - An Armor Checksum - The Armor Tail, which depends on the Armor Headerline. PGP Formats - Open PGP BOF Page 5 An Armor Headerline is composed by taking the appropriate headerline text surrounded by five (5) dashes (-) on either side of the headerline text. The headerline text is chosen based upon the type of data that is being encoded in Armor, and how it is being encoded. Headerline texts include the following strings: BEGIN PGP MESSAGE -- used for signed, encrypted, or compressed files BEGIN PGP PUBLIC KEY BLOCK -- used for transferring public keys BEGIN PGP MESSAGE, PART X/Y -- used for multi-part messages, where the armor is split amongst Y files, and this is the Xth file out of Y. The Armor Headers are pairs of strings that can give the user or the receiving PGP message block some information about how to decode or use the message. The Armor Headers are a part of the armor, not a part of the message, and hence should not be used to convey any important information, since they can be changed in transport. The format of an Armor Header is that of a key-value pair. PGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor. Unknown keys should be reported to the user, but PGP should continue to process the message. Currently defined Armor Header Keys include "Version" and "Comment," which define the PGP Version used to encode the message and a user-defined comment. The Armor Checksum is a 24-bit CRC converted to four characters of radix-64 encoding, prepending an equal-sign (=) to the four character code. The CRC is computed by using the generator 0x864CFB and an initialization of 0xB704CE. The accumulation is done on the data before it is converted to radix-64, rather than on the converted data. For more information on CRC functions, the reader is asked to look at chapter 19 of the book "C Programmer's Guide to Serial Communications," by Joe Campbell. The Armor Tail is composed in the same manner as the Armor Headerline, except the string "BEGIN" is replaced by the string "END." 3. Data Element Formats This section describes the data elements used by PGP. 3.1 Scalar numbers Scalar numbers are unsigned, and are always stored in big-endian format. Thus, the value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]). 3.2 Multi-Precision Integers Multi-Precision Integers (also called MPIs) are unsigned integers used to hold large integers such as ones used in cryptographic calculations. An MPI consists of two pieces: a two-octet scalar that is the length of the MPI in bits followed by a string of octets that contain the actual integer. These octets form a big-endian number; a big-endian number can be made into an MPI by prefixing it with the appropriate length. PGP Formats - Open PGP BOF Page 6 Examples: (all numbers are in hexadecimal) The string of octets [00 01 01] forms an MPI that has a value of 1. The string [00 09 01 ff] forms an MPI with the value of 511. Additional rules: The size of an MPI is ((MPI.length + 7) / 8) + 2. The length field of an MPI describes the length starting from its most significant non-zero bit. Thus, the MPI [00 02 01] is not formed correctly. It should be [00 01 01]. 3.3 Strings A string consists of a one-octet length and then N octets of string data. 3.4 Time fields A time field is a four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 GMT. 4. Packets This section describes the packets used by PGP. 4.1 Overview A packet is a chunk of data that has a tag specifying its meaning. A PGP message, keyring, certificate, and so forth consists of a number of packets. Some of those packets may contain other PGP packets (for example, a compressed data packet, when uncompressed, contains PGP packets). Each packet consists of a packet header, followed by the packet body. The packet header is of variable length. 4.2 Packet Headers The first octet of the packet header is called the "Cipher Type Byte." It determines the format of the header. Its high-order bit (0x80) must be set. If the next bit (0x40) is set, it is a new format packet. If it is clear, then it is an old format packet. New format packets can only be decoded by PGP V5.0 or later. Thus, software that needs to be compatible with earlier versions of PGP must only use old format packets. In an old format packet, the packet tag resides in the middle four bits ((ctb & 0x3c) >> 2). The two low order bits (ctb & 0x3) denote the number of octets following the CTB that hold the length of the packet body. The meaning of the length-type is: PGP Formats - Open PGP BOF Page 7 0 - The packet has a one-octet length. The header is 2 octets long. 1 - The packet has a two-octet length. The header is 3 octets long. 2 - The packet has a four-octet length. The header is 5 octets long. 3 - The packet is of indeterminate length. The header is 1 byte long, and the application must determine how long the packet is. If the packet is in a file, this means that the packet extends until the end of the file. In general, an application should not use indeterminate length packets. In a new format packet, the low-order six bits (cth & 0x3f) form the packet tag. The length of the packet is found in the next one or two octets, thus: If the next octet is 191 or less, then that is the length of the packet body. If that octet is between 192 and 223, then the length of the packet body is held in the two octets following the CTB with the following formula: bodyLen = ((p[1] - 192) * 256) + p[2] + 192; Note that this yields a maximum packet body length of 8383 octets for this type of packet. If the second octet is 224 or greater (note that 224 is E0 in hexadecimal, or 11100000 in binary), then the low-order five bits form the length of the packet body with the formula: bodyLen = 1 << (p[1] & 0x1f); In English, the packet body length is a power of two. Its maximum length is 2**31 octets long. Note that there is no way to form a new-format packet that is longer than 8383 octets and not a power of two in length. Please note that in all of these explanations, the total length of the packet is the length of the header plus the length of the body. 4.3 Packet Tags The packet tag denotes what type of packet the body holds. Note that old format packets can only have tags less than 16, whereas new format packets can have tags as great as 63. The defined tags are: 0 -- Reserved. A packet must not have a tag with this value. 1 -- Encrypted Session Key Packet 2 -- Signature Packet 3 -- Conventionally Encrypted Session Key Packet 4 -- One-Pass Signature Packet 5 -- Secret Key Packet 6 -- Public Key Packet 7 -- Secret Subkey Packet 8 -- Compressed Data Packet 9 -- Symmetrically Encrypted Data Packet 10 -- Obsolete Literal Packet 11 -- Literal Data Packet 12 -- Trust Packet 13 -- Name Packet PGP Formats - Open PGP BOF Page 8 14 -- Subkey Packet 15 -- Reserved 16 -- Comment Packet 5.0 Packet Types This section describes some of the more interesting packet types. 5.1 Encrypted Session Key Packets The encrypted session key packet (tag 1) describes how a message is encrypted. One or more of these packets precede a Symmetrically Encrypted Data Packet, for each PGP key the message is encrypted to. The recipient of the message finds a session key that is encrypted to their public key, decrypts the session key, and then uses the session key to decrypt the message. The body of this packet consists of: - A one-octet number giving the version number of the packet type, either 2 or 3. All modern versions of PGP generate type 3 packets. - An eight-octet number that gives the ID of the public key that the session key is encrypted to. - A one-octet number giving the public-key algorithm used. - A string of octets that is the encrypted session key. This string takes up the remainder of the packet, but is not explicitly counted. 5.2 Conventional Encrypted Session-Key Packets This packet (tag 3) describes a session key that has been encrypted to a secondary symmetric cipher. This allows a message to be encrypted to a number of public keys, and also to one or more pass phrases. This packet type is new, and is not generated by PGP 2.x or PGP 5.0. The body of this packet consists of: - A one-octet version number. The current version is 4. - A one-octet number describing the symmetric algorithm used. - A "string-to-key" object. This is described below. It is 2, 10, or 11 octets long. - The encrypted session key itself, which is decrypted with the string-to-key object. The string-to-key object has this format: 5.3 One-Pass Signature Packets This packet (tag 4) is also a new packet type, but may be generated by PGP 5.0 or later. This in an in-line packet that tells the processing software how to compute a signature so that it does not have to read the entire message before starting. PGP Formats - Open PGP BOF Page 9 The body of this packet consists of: - A one-octet version number. The current version is 3. - A one-octet signature type. Signature types are described later in this document. - A one-octet number describing the hash algorithm used. - A one-octet number describing the public key algorithm used. - An eight-octet number holding the key ID of the signing key. - A one-octet number holding a flag showing if the signature is nested. 5.4 Symmetrically Encrypted Data Packet This packet (tag 9) contains encrypted data. When it has been decrypted, it will typically contain other packets (often literal data packets or compressed data packets). The body of this packet consists of: - Eight octets of initialization data. This is arbitrarily chosen material that starts the encryption engine. This serves a similar purpose to an initialization vector in a cipher-block- chaining engine. It helps to reduce the chance of information leaks caused by known-plaintext attacks. - Two octets of data that are used to check the decryption process. The seventh and eighth octets of decrypted data must match these two octets. - The remainder of the packet is encrypted data. 5.5 Compressed Data Packet This packet (tag 8) contains compressed data. Typically, this packet is found as the contents of an encrypted packet, and contains literal data packets. The body of this packet consists of: - One octet that gives the algorithm used to compress the packet. - The remainder of the packet is compressed data. 5.6 Literal Data Packet A literal data packet (tag 11) contains the body of a message, data that is not to be further interpreted. The body of this packet consists of: - A one-octet field that describes how the data is formatted. If it is a 'b' (0x62), then the literal packet contains binary data. If it is 't' (0x74), then it contains text data, and thus may need line ends converted to local form, or other text-mode changes (similar to FTP's text mode). RFC 1991 also defines a 'local' mode for machine-local conversions, but does not define it. Curiously, it specifies that the character for it is '1' (numeral one) (which this author thinks might be a typo for 'l' (lower-case ell), and does not give its hexadecimal equivalent. - A counted string giving a file name. - A four-octet number that indicates the modification date of the file, or the creation time of the packet, or a zero that indicates the present time. - The remainder of the packet is literal data. PGP Formats - Open PGP BOF Page 10 5.7 Obsolete Literal Packet An experimental version of PGP used this packet (tag 10) as the literal packet, but no released version of PGP generated literal packets with this tag. With PGP 5.x, this packet has been re-assigned and is reserved for use as a marker packet. PGP 5.x makes a packet and puts it at the start of a message that mixes RSA and DSS keys, so that PGP 2.x will recognize it as a legal PGP message, but one that it is not equipped to decode. You may use these packets for similar purposes, and should ignore any you find. The packet that PGP 5.x uses contains three octets of data, holding the string "PGP." 5.8 Key Material Packet A key material packet contains all the information about a public or private key. There are four variants of this packet type, and two major versions. Consequently, this section is complex. A public-key packet (tag 6) starts a series of packets that forms a PGP certificate (or PGP key, as it is commonly known). A subkey packet (tag 14) has exactly the same format, but denotes a subkey. If it had the same tag, then it would be impossible to tell a subkey from the start of another certificate. A secret-key packet (tag 5) contains all the information that is found in a public key packet, including the public key material, but also includes the secret key material after all the public-key fields. As you would expect, a secret subkey packet (tag 7) is the secret-key analog of the secret key packet, and has exactly the same format. There are two versions of key-material packets. Version 3 packets are PGP 2.6 packets. Version 2 packets are identical in format to Version 3 packets, but are generated by PGP 2.5 or before. This document hereafter ignores them. PGP 5.0 introduces version 4 packets, with new fields and semantics. PGP 5.x uses version 3 packets for RSA keys, and version 4 packets for DSS/DH keys. Note that there is no reason that there cannot be a V4 RSA key (except that it is not compatible with previous versions of PGP), nor a reason that there cannot be a V3 DSS key. A version 3 packet contains: - A one-octet version number. - A four-octet number denoting the time that the key was created. - A two-octet number denoting the time in days that this key is valid. If this number is zero, then it does not expire. - A one-octet number denoting the public key algorithm of this key - A series of multi-precision integers comprising the key material. An RSA key has two MPIs: the RSA public modulus (n), followed by the public exponent (e). A Diffie-Hellman key has three MPIs: the prime (p), the generator (g), and the public key (k). A DSS key has four MPIs: the prime (p), the group order (o), the generator(g), and the public key (k). PGP Formats - Open PGP BOF Page 11 The fingerprint of the key is formed by hashing the body (but not the two-octet length) of the MPIs that form the key material with MD5. The eight-octet key ID of the key is formed by taking the low 64 bits of the public modulus of an RSA key. Note that no released version of PGP has created a V3 key with any other public key algorithm other than RSA. PGP 5 still generates its RSA keys in V3 format to ensure interoperability with V2.x. Since the release of PGP 2.6, there have been a number of improvements desired in the key format. For example, making the key id be a function of the public modulus makes it easy for a person to purposely create a key that has the same key id as some existing key. Similarly, MD5 is no longer the preferred hash algorithm, and not hashing the length of an MPI with its body increases the chances of a fingerprint collision. The version four packet format is similar to the V3 format except for the following changes: - There is no validity period field. - The fingerprint is constructed by taking the SHA-1 hash of . - The key ID is the low 64 bits of the fingerprint. 5.9 User-Name Packet A user-name packet is a counted string with a one-octet length. By convention, it is an RFC 822 mail name, but there are no restrictions on its content. 5.10 Signature Packets A signature packet describes a binding between some public key and some data. The most common signatures are a signature of a file or a block of text, and a signature that is a certification of a user name. There are a number of meanings of a signature, which are specified in a signature-type octet in any given signature. These meanings are: - 0x00: Signature of a binary document. Typically, this means the signer owns it, created it, or certifies that it has not been modified. - 0x01: Signature of a canonical text document. Typically, this means the signer owns it, created it, or certifies that it has not been modified. - 0x10: The generic certification of a user name and public-key packet. The issuer of this certification does not make any particular assertion as to how well the certifier has checked that the owner of the key is in fact the person described by the user name. Note that all PGP "key signatures" are this type of certification. - 0x11: This is a persona certification of a user name and public-key packet. It means that the issuer of this certification has not done any verification of the claim that the owner of this key is the user name specified. Note that no released version of PGP has generated this type of certification. PGP Formats - Open PGP BOF Page 12 - 0x12: This is the casual certification of a user name and public-key packet. It means that the issuer of this certification has done some casual verification of the claim of identity. Note that no version of PGP has generated this type of certification, nor is there any definition of what constitutes a casual certification. - 0x13: This is the positive certification of a user name and public-key packet. It means that the issuer of this certification has done substantial verification of the claim of identity. Note that no version of PGP has generated this type of certification, nor is there any definition of what constitutes a positive certification. Please also note that the vagueness of these certification systems is not a flaw, but a feature of the system. Because PGP places final authority for validity upon the receiver of a certification, it may be that one authority's casual certification might be more rigorous than some other authority's positive certification. SigSubkeyCert = 0x18, SigKRev = 0x20, SigSubkeyRev = 0x28, SigKSRev = 0x30, SigTimeStamp = 0x40 6. Constants This section describes the constants used in PGP Version 5.x. 6.1 Public Key Algorithms 1 - RSA 16 - Diffie-Helman, El Gamal variant 17 - DSS (Digital Signature Algorithm) 6.2 Symmetric Key Algorithms 0 - Plaintext 1 - IDEA 2 - Triple-DES (DES-EDE, 168 bit key) 3 - CAST5 (128 bit key) 6.3 Compression Algorithms 0 - Uncompressed 1 - ZIP 6.4 Hash Algorithms 1 - MD5 2 - SHA-1 ? - RIPE-MD/160 7. Transferable Public Keys Public keys may transferred between PGP users. The essential elements of a transferable public key are: PGP Formats - Open PGP BOF Page 13 (a) One public-key packet (b) One or more user-ID packets (c) Zero or more signature packets The public-key packet occurs first. Each of the following user ID packets provides the identity of the owner of this public key. If there are multiple user-ID packets, this corresponds to multiple means of identifying the same unique individual user; for example, a user may enjoy the use of more than one e-mail address, and construct a user-ID packet for each one. Immediately following each user-ID packet, there are zero or more signature packets. Each signature packet is calculated on the immediately preceding user-ID packet and the initial public key packet. The signature serves to certify the corresponding public key and user ID. In effect, the signer is testifying to his or her belief that this public key belongs to the user identified by this user ID. 8. PGP 5.0 Enhanced Key Formats With PGP 5.0, a more flexible PGP key format was introduced. The new key format allows for two new features. One is the ability to support a key that has one public key to do authentication and a second to do encryption. The other new feature is the ability to easily expand the signature packets. Currently, both authentication and encryption are done using the RSA public key cryptosystem. The RSA algorithm uses a single public/private key pair to perform both operations. The existing PGP key format only supports algorithms that digitally sign and encrypt with a single key. The enhanced key format supports algorithms that can use a different key pair for each operation. The first example of this new flexibility is PGP 5.0's support of keys that use NIST's Digital Signature Standard (DSS) for digital signatures and the ElGamal variation of Diffie-Hellman for encryption and decryption. PGP 5.0 continues to support both the RSA algorithm and the existing PGP key format when used with RSA. The new signature packet (version 4) includes subpackets to easily add new attributes to a signature. Further, two types of subpackets exist; a group of subpackets that is included in the hash used by the signature and a group that is not. The subpackets can be either attributes of the signature packet, or they can be an assertion by the signer about the key being signed. Currently, this new format is only generated for signatures on Diffie-Hellman/DSS keys. This prevents any backward compatibility problems since all RSA keys still use version 3 signatures and all software that supports Diffie-Hellman/DSS also supports the new signature packets. 8.1 Key Structures The format of an existing PGP key using RSA is as follows. Entries in square brackets are optional and ellipses indicate repetition. PGP Formats - Open PGP BOF Page 14 RSA Public Key [Revocation Self Signature] UserID [Signature ...] [UserID [Signature ...] ...] Each signature certifies the RSA public key and the preceding UserID. The RSA public key can have many UserIDs and each UserID can have many signatures. The format of the new PGP key type that requires two public keys is very similar except that the second key is added to the end as a 'subkey' of the primary key. Primary-Key [Revocation Self Signature] UserID [Signature ...] [UserID [Signature ...] ...] [Subkey Primary-Key-Signature] The subkey always has a single signature after it that is issued using the primary key to tie the two keys together. The new format can use either the new signature packets or the existing signature packets. In a Diffie-Hellman/DSS key, the DSS public key is the primary key, the Diffie-Hellman public key is the subkey, and either version 3 or 4 of the signature packet can be used. 8.2 Public Key Certificate Packet Structure To accommodate the addition of the subkey construction, a new version of the public-key-certificate packet was created. Packets with a version of '3' are still created for PGP keys that use RSA public keys. For specifics on version 3 packets, see RFC 1991. The terms and formatting used here are consistent with that RFC. A Cipher Type Byte (CTB) with bits 5-2 of 0110 indicates a primary public-key-certificate packet. This can be either an existing RSA key with a packet version of 3 or a DSS key with a version of 4. A new packet type is now defined for the subkey. The CTB of the subkey packet has bits 5-2 of 1110. Notice that this used to indicate a comment packet. These packet-type bits were selected because no previous version of PGP ever emitted comment packets but they did properly ignore them. This provides some backwards compatibility with existing PGP implementations. Below are the complete definitions for the primary and subkey public key packets. Support for RSA and Diffie-Hellman/DSS keys is described. RSA Public Key Certificate Packet ("old format") a) packet structure field with CTB bits 5-2 = 0110 (2 or 3 bytes); b) version number = 3 (1 byte); c) time stamp of key creation (4 bytes); d) validity period in days (0 means forever) (2 bytes); PGP Formats - Open PGP BOF Page 15 e) algorithm (1 byte): 1 = RSA, f) Algorithm specific fields. Algorithm Specific Fields for RSA keys: f.1) multiprecision integer (MPI) of RSA public modulus n; f.2) MPI of RSA public encryption exponent e. New Public Key Certificate Packet a) packet structure field with (2 or 3 bytes): Bits 5-2 of CTB = 0110 means primary key packet, Bits 5-2 of CTB = 1110 means subkey packet; b) version number = 4 (1 byte); c) time stamp of key creation (4 bytes); e) algorithm (1 byte): 1 = RSA (not presently generated), 16 = Diffie-Hellman, 17 = DSS; f) Algorithm specific fields. Algorithm Specific Fields for DSS keys: f.1) MPI of DSS prime p; f.2) MPI of DSS group order q (q is a prime divisor of p-1); f.3) MPI of DSS group generator g; f.4) MPI of DSS public key value y (= g**x where x is secret). Algorithm Specific Fields for Diffie-Hellman keys: f.1) MPI of Diffie-Hellman prime p; f.2) MPI of Diffie-Hellman group generator g; f.3) MPI of Diffie-Hellman public key value y (= g**x where x is secret). 8.3 Signature Packet Structure Version 4 of the signature packet adds the concept of hashed and non-hashed subpackets. Since this version is not recognized by previous versions of PGP, it is currently only being generated in conjunction with version 4 public-key-certificate packets (i.e., Diffie-Hellman/DSS PGP keys). NOTE: The order and contents of the data that is hashed in a version 4 signature packet needs further detail. Here is the specification of a version 4 signature packet: a) packet structure field with CTB with bits 5-2 = 0010 (2 or 3 bytes); b) version number = 4 (1 byte); c) signature classification (hashed) (1 byte); d) public key algorithm (hashed) (1 byte): 1 = RSA (not presently generated), 16 = Diffie-Hellman, 17 = DSS; PGP Formats - Open PGP BOF Page 16 e) hash algorithm (hashed) (1 byte): 1 = MD5, 2 = SHA; f) length of hashed subpacket data (hashed) (2 bytes); g) hashed subpacket data (hashed) (f bytes): - signature creation time, - key expiration time, - preferred symmetric encryption algorithms; h) length of non-hashed subpacket data (2 bytes); i) non-hashed subpacket data (h bytes): - signer key ID; j) first 2 bytes of message digest (16 bit checksum); k) MPI of public key signature l) MPI #2 of public key signature (for DSS signatures only) Fields g) and i) consist of signature subpackets. Below is the specification of signature subpackets. The list of subpackets may grow in the future. Unrecognized packets should be skipped unless marked as critical. a) subpacket length (1 or 2 bytes): Length includes the type byte but not this length, 1st byte < 192, then length is one byte, 1st byte >= 192, then length is 2 bytes and equal to (1st byte & 0x3F) * 256 + (2nd byte) + 192; b) subpacket type (1 byte): If bit 7 is set, subpacket understanding is critical, 2 = signature creation time, 9 = key expiration time, 11 = preferred symmetric algorithms, 16 = key ID of signer, c) subpacket specific data (b bytes); Several types of subpackets are currently defined. Some subpackets apply to the signature itself and some are attributes of the key. Signature creation time (4 byte time field) (Hashed) The time the signature was made. Always included with new signatures. Key ID of signer (8 byte key ID) (Non-hashed) The PGP key ID of the person signing the key. Key expiration time (4 byte time field) (Hashed) The validity period of the key. This is the number of seconds after the key creation time that the key expires. If this is not present or has a value of zero, the key never expires. This is found on a self-signature. Preferred symmetric algorithms (array of 1 byte) (Hashed) Symmetric algorithm numbers that indicate which algorithms the key holder prefers to use. This is an ordered list of bytes with the most preferred listed first. It should be assumed that only algorithms listed are supported by the recipient's software. Algorithm numbers are provided below. If this subpacket is not included, IDEA is assumed. This is found on a self-signature. PGP Formats - Open PGP BOF Page 17 8.4 Diffie-Hellman/DSS Key IDs and Fingerprints A Diffie-Hellman/DSS fingerprint is the 160-bit SHA-1 hash of a few header bytes followed by the entire public key packet starting with the version field. The key ID is either the low order 32 bits or 64 bits of the fingerprint. Here are the fields of the hash material: a.1) 0x99 (1 byte) a.2) high order length byte of (b)-(f) (1 byte) a.3) low order length byte of (b)-(f) (1 byte) b) version number = 4 (1 byte); c) time stamp of key creation (4 bytes); e) algorithm (1 byte): 17 = DSS; f) Algorithm specific fields. Algorithm Specific Fields for DSS keys: f.1) MPI of DSS prime p; f.2) MPI of DSS group order q (q is a prime divisor of p-1); f.3) MPI of DSS group generator g; f.4) MPI of DSS public key value y (= g**x where x is secret). 8.5 New Algorithm and Signature Classification Types Several new algorithm types were added to support Diffie-Hellman/DSS keys. Below are the new public-key-encryption algorithm numbers: Diffie-Hellman 16 DSS 17 DSS uses a different message digest algorithm, the Secure Hash Algorithm (SHA-1). This is the only message-digest-algorithm number added: SHA-1 2 Below are the preferred symmetric algorithm numbers: IDEA 1 (not new) Triple DES 2 CAST5 3 A single new signature classification was added for the signature packet that ties the subkey to the primary key. Subkey Signature 24 8.6 Interoperability Starting with PGP 5.0, PGP's products support this new format and the sending and receiving of mail protected using either RSA or Diffie-Hellman/DSS keys. A keyring can contain both types of keys and you can send a piece of mail to people with either key type. PGP Formats - Open PGP BOF Page 18 Users of previous versions of PGP cannot accept keys that use Diffie-Hellman/DSS. PGP is releasing patches for most versions that provide some support for Diffie-Hellman/DSS keys. The patches allow prior versions to interoperate better with Diffie-Hellman/DSS keys. The patched versions still do not support generating Diffie-Hellman/DSS keys or usingthem to send or receive encrypted mail. 8.7 Future Formats Additional information on PGP formats is being provided to the public in order for others to build compatible or complimentary systems that support PGP. PGP Formats - Open PGP BOF Page 19 From owner-ietf-open-pgp Thu Jul 31 01:46:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA08716 for ietf-open-pgp-bks; Thu, 31 Jul 1997 01:46:36 -0700 (PDT) Received: from foo.hhhh.org (wiml@foo.hhhh.org [204.118.128.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id BAA08712 for ; Thu, 31 Jul 1997 01:46:30 -0700 (PDT) Received: from localhost (wiml@localhost) by foo.hhhh.org (8.6.12/8.6.9) with SMTP id BAA20356; Thu, 31 Jul 1997 01:50:24 -0700 Date: Thu, 31 Jul 1997 01:50:21 -0700 (PDT) From: W Lewis To: ietf-open-pgp@imc.org cc: jude shabry Subject: Re: PGP Message Exchange Formats Internet Draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Some initial comments on the draft, mostly nits. - The expanding integer formats used by new-style CTBs and by version-4 signature subpacket fields should probably be given names and added to the catalog of types in section 3. The two formats are slightly different; what is the reasoning behind this? - Section 2.4.1 does not fully describe the CRC used with ascii armor. - Section 7 does not mention the possibility of a subkey packet occurring in a transferable public key... I assume this is just an oversight. - The draft does not describe how session keys and hash digests are encoded into MPIs for use in public-key algorithms. IMHO this is the most glaring omission. Wim Lewis / wiml@hhhh.org From owner-ietf-open-pgp Sat Aug 2 18:45:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA06747 for ietf-open-pgp-bks; Sat, 2 Aug 1997 18:45:43 -0700 (PDT) Received: from ns.adis.at (root@ns.adis.at [195.64.0.34]) by mail.proper.com (8.8.5/8.7.3) with SMTP id SAA06742 for ; Sat, 2 Aug 1997 18:45:37 -0700 (PDT) Received: from [195.64.0.77] (asy207.adis.at [195.64.0.77]) by ns.adis.at (8.6.12/8.6.9) with SMTP id DAA16496; Sun, 3 Aug 1997 03:49:19 +0200 Message-Id: <199708030149.DAA16496@ns.adis.at> Subject: Re: PGP Message Exchange Formats draft-ietf-pgp-formats00.txt Date: Sun, 3 Aug 97 03:48:53 +0200 x-sender: yog@email.adis.at x-mailer: Claris Emailer 1.1 From: Gerald Young To: "jude shabry" cc: , Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On 7/31/97 02:02, jude shabry wrote: >INTERNET-DRAFT Gail Haspert >Security PGP, Inc. >Expires in six months Editor > July 30 1997 > >PGP Message Exchange Formats > > Some comments on the contents, syntax and semantcs of the = aforementined document. Regards -- Gerald -BEGIN- > 2.4 Radix-64 conversion > ...converting > the raw 8-bit binary octet stream to a stream of printable ASCII > characters, called Radix-64 encoding or ASCII Armor. Isn't the term "octet" a synonym for 8-bit data entities, defined as = such in RFC ???? "ASCII characters" are really "7-bit US-ASCII octets" > Similar to MIME encoding, the process of Radix-64 encoding an MIME defines several encodings, use an explicit reference to "base64" = encoding (RFC ???? Section ?.?) > ...8-bit binary stream of data... "binary octet stream" > is as follows. Every three subsequent 8 bit binary octets... simply "octets" instead of "8 bit binary octets" (8-bit binary = octets). > are mapped into four subsequent 6-bit ASCII characters. what are 6-bit ASCII characters? use "US-ASCII". "6-bit coding subset = of US-ASCII" In general the process is already defined and phrased in some MIME = documents, so that wording SHOULD be used for consistency IMHO. > Radix-64 encoding also appends a CRC to detect transmission errors. This really is a difference from base64. How is padding handled? This is explicitely stated in base64 specs. > This radix-64 conversion, is a wrapper around the binary PGP > messages, and is used to protect the binary messages during > transmission over non-binary channels, such as Internet Email. How does this interoperate with 8bitMIME capable ESMTP mailers? = Explicite reference. > The following table defines the mapping. The characters used are the > upper- and lower-case letters, the digits 0 through 9, and the > characters + and /. The carriage-return and linefeed characters > aren't used in the conversion, nor is the tab or any other character > that might be altered by the mail system. The result is a text file > that is "immune" to the modifications inflicted by mail systems. Is this anyhow different to MIME base64 encoding? > To encode an arbitrary 3 octets, separate the bit stream logically how is an octet transformed into an bit stream, which bit is first...? > into four 6-bit groups, calculate the decimal value of the 6-bit "decimal value" ??? decimal is because of the table below, but not required by the encoding process? skip "decimal", use "use as an = index". > group, and replace it with the corresponding character from the table > below. > Decoding is the exact opposite operation. Really? Nothing more :) This is a to-be standard, defining things not = merely stating them to happen... Add one or more paragraphs on decoding... > 6-bit Value Mapped to Character Encoding See? no "decimal" mentioned in the table heading > Hex octet 0x17 0x3A 0xA3 >Example: Binary stream 00010111 00111010 10100011 > Translate to 6bit 000101 110011 101010 100011 > Decimal 5 51 42 35 > Final Character F z q j OK, this serves as example and definition on bit-streaming... But, what to to if there are not enough octets as input, how to pad? And how to detect the end of the to-be-decoded stream, as there is no length field anywhere... > It is possible to use PGP to convert any arbitrary file to ASCII > Armor. When this is done, PGP tries to compress the data before it > is converted to Radix-64. Terms "ASCII Armor" and "Radix-64" are used interchangable, by = intention. What about MIME base64 content encoding of "binary" PGP message data? binary data --> ASCII Armor (as per 2.4.1 below) --> compress ? --> Radix-64 ---> MIME... >2.4.1 ASCII Armor Formats > > When PGP encodes data into ASCII Armor, it puts specific headers > around the data, so PGP can reconstruct the data at a future time. > PGP tries to inform the user what kind of data is encoded in the > ASCII armor through the use of the headers. > > ASCII Armor is created by concatenating the following data: ok, we are now creating ASCII Armor... > > - An Armor Headerline, appropriate for the type of data > - Armor Headers > - A blank line What is a line, BTW. Obviously now we need an RFC822 type definition of "line" (sequence of octets terminated by an sequence?) > - The ASCII-Armored data Oops. This is an recursive definition, as we are about to specify how ASCII-Armored data is created. Obviously this should read "The Radix-64 encoded data" > - An Armor Checksum Same as above, should read "An Radix-64 Checksum of the encoded data". > - The Armor Tail, which depends on the Armor Headerline. > An Armor Headerline is composed by taking the appropriate headerline > text surrounded by five (5) dashes (-) on either side of the (-) --> (US-ASCII 0x?? "-") > headerline text. The headerline text is chosen based upon the type > of data that is being encoded in Armor, and how it is being encoded. Is it "Armor" or "ASCII Armor" or "ASCII-Armor" or what? > Headerline texts include the following strings: Is an enumeration to follow or an example? > BEGIN PGP MESSAGE -- used for signed, encrypted, or compressed files > BEGIN PGP PUBLIC KEY BLOCK -- used for transferring public keys > BEGIN PGP MESSAGE, PART X/Y -- used for multi-part messages, where > the armor is split amongst Y files, > and this is the Xth file out of Y. Use a tabular approach here, like: "BEGIN PGP MESSAGE" used for signed, encrypted, or compressed files "BEGIN PGP PUBLIC KEY BLOCK" used for transferring public keys "BEGIN PGP MESSAGE, PART X/Y" used for multi-part messages, where the armor is split amongst Y files, and this is the Xth file out of Y. Make clear whether this is an exhaustive list ("definition") or only examples. How are new value strings introduced, and what to to with undefined/unkown strings. > The Armor Headers are pairs of strings that can give the user or the > receiving PGP message block some information about how to decode or > use the message. Strange concept, however :) > ...The Armor Headers are a part of the armor, not a > part of the message, and hence should not be used to convey any > important information, since they can be changed in transport. How could this happen, they are to contain base64/radix-64 characters considered to be mail save. Any other encoding of the "ASCII Armor" is to be transparent and is removed/reversed before the ASCII Armor is passed to the PGP layer. What about BINARY Armor? Maybe introduce something streamable like = GIF or PNG. > The format of an Armor Header is that of a key-value pair. PGP > should consider improperly formatted Armor Headers to be corruption > of the ASCII Armor. Unknown keys should be reported to the user, but > PGP should continue to process the message. Currently defined Armor > Header Keys include "Version" and "Comment," which define the PGP > Version used to encode the message and a user-defined comment. This paragraph obviously deals with the above mentioned "Armor = Headerlines", not "Armor Headers". Armor Headerlines are to be built after RFC822 lines, thus possibly = adopting the folding and encoding (Q-encoding) rules defined there and = elsewhere. Thus Headerlines are just like "Subject:" or "Comment:" header lines = of email messages. >The Armor Checksum is a 24-bit CRC converted to four characters of >radix-64 encoding, prepending an equal-sign (=3D) to the four character = code. "... to the resulting four characters." >The CRC is computed by using the generator 0x864CFB and an initialization >of 0xB704CE. The accumulation is done on the data before it is converted >to radix-64, rather than on the converted data. For more information on >CRC functions, the reader is asked to look at chapter 19 of the book >"C Programmer's Guide to Serial Communications," by Joe Campbell. This complete para above is not intented properly. Got the ISBN of that book. A References section is missing from the = draft. > The Armor Tail is composed in the same manner as the Armor > Headerline, except the string "BEGIN" is replaced by the string > "END." Its "Headerline", but "Tail"; maybe use "Tail line" and "Header line". An example of a short message in ASCII Armor is missing here now. >3. Data Element Formats >This section describes the data elements used by PGP. An empty line is missing as seperator. >3.1 Scalar numbers > >Scalar numbers are unsigned, and are always stored in big-endian format. >Thus, the value of a two-octet scalar is ((n[0] << 8) + n[1]). The value >of a four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + = n[3]). Add example. >The string of octets [00 01 01] forms an MPI that has a value of 1. The = string >[00 09 01 ff] forms an MPI with the value of 511. reformat into seperate paragraphs and use uppercase characters for = hex digits A..F. --> The string of octets [00 01 01] forms a MPI that has a value of 1. --> --> The string of octets [00 09 01 FF] forms a MPI with the value of = 511. Hmm, thus MPI's are quite different from Radix-64 bit streams, as the = bit stream is aligned differently. But: >Additional rules: > >The size of an MPI is ((MPI.length + 7) / 8) + 2. --> The size of a MPI in octets is ((MPI.length + 7) / 8) + 2. =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D >The length field of an MPI describes the length starting from its most >significant non-zero bit. Thus, the MPI [00 02 01] is not formed = correctly. >It should be [00 01 01]. This clears things up a bit, but this should be placed before the = Example anyway. Is it "an MPI" or "a MPI" ?! >3.3 Strings > >A string consists of a one-octet length and then N octets of string data. "an (!) one-octet", better "an one-octet scalar number specifying the = length, followed by that number of octets of string data." Add an example, say "PGP". >3.4 Time fields > >A time field is a four-octet number containing the number of seconds >elapsed since midnight, 1 January 1970 GMT. "four-octet scalar number". Is this the UNIX epoch... Give one example (maybe 1 January 2000 :) ) and give the maximum = date/time possible (not taking leap seconds and such into account...:) ) >4.2 Packet Headers > >The first octet of the packet header is called the "Cipher Type Byte." "Byte" is ambiguous?! Define "ctb" or "CTB" used below. This first octet is also the first octet of the entire packet, or = else? And, packets headers are obviously not covered by section 3, as they = are not defined there (an design flaw of early times, I guess). Are "Tags" (as mentioned in 4.1 Overview) always single octets, then = they can be defined in section 3. >In an old format packet, the packet tag resides in the middle four bits >((ctb & 0x3c) >> 2). The two low order bits (ctb & 0x3) denote the number use "0x3C" >of octets following the CTB that hold the length of the packet body. "length" --> "length-type" Thus with ((ctb & 0xFC) >> 2) --> 64..127 for old formats... >The meaning of the length-type is: >0 - The packet has a one-octet length. The header is 2 octets long. >1 - The packet has a two-octet length. The header is 3 octets long. >2 - The packet has a four-octet length. The header is 5 octets long. >3 - The packet is of indeterminate length. The header is 1 byte long, >and the application must determine how long the packet is. If the packet >is in a file, this means that the packet extends until the end of the = file. >In general, an application should not use indeterminate length packets. Use table format: 0 The packet has a one-octet length. The header is 2 octets long. 1 The packet has a two-octet length. The header is 3 octets long. 2 The packet has a four-octet length. The header is 5 octets long. 3 The packet is of indeterminate length. The header is 1 byte = long, and the application must determine how long the packet is. If = the packet is in a file, this means that the packet extends until the end = of the file. In general, an application should not use indeterminate length = packets. >In a new format packet, the low-order six bits (cth & 0x3f) form the = packet >tag. The above text on old format packets used "ctb"?! 0x3F >If the next octet is 191 or less, then that is the length of the packet Use "second octet". >body. If that octet is between 192 and 223, then the length of the packet >body is held in the two octets following the CTB with the following = formula: Another design flaw with v5.0: why not use MPI's here too. Start a new para for the 192 to 223 case and maybe use also "second = octet". Rephrase to "high-order bit clear" type of description. Maybe use hex = numbers here too. "CTB" used here again, should be "ctb"? > bodyLen =3D ((p[1] - 192) * 256) + p[2] + 192; what is p obviously pointing to? >Note that this yields a maximum packet body length of 8383 octets for this >type of packet. > >If the second octet is 224 or greater (note that 224 is E0 in = hexadecimal, or "If that octet is between 224 and 255...", "0xE0" (you already used = the uppercase here) >11100000 in binary), then the low-order five bits form the length of the >packet body with the formula: > > bodyLen =3D 1 << (p[1] & 0x1f); > >In English, the packet body length is a power of two. Its maximum length >is 2**31 octets long. Note that there is no way to form a new-format = packet >that is longer than 8383 octets and not a power of two in length. > >Please note that in all of these explanations, the total length of the >packet is the length of the header plus the length of the body. >4.3 Packet Tags > >The packet tag denotes what type of packet the body holds. Note that old >format packets can only have tags less than 16, whereas new format = packets >can have tags as great as 63. The defined tags are: > >0 -- Reserved. A packet must not have a tag with this value. >1 -- Encrypted Session Key Packet This table uses yet another format... unify. Use Obsolete and Reserved and New as First descriptive element, maybe = form another column. What to to with undefined packet tags encountered? Packet Tag 16 is a new (v5.0) packet type?! >5.0 Packet Types > >This section describes some of the more interesting packet types. Rephrase. This is the definition document, should describe all packet = types?! >5.1 Encrypted Session Key Packets Add packet tag value to the heading: "5.1 Encrypted Session Key = Packets (Packet Tag 1)" >The body of this packet consists of: > > - A one-octet number giving the version number of the packet type, > either 2 or 3. All modern versions of PGP generate type 3 > packets. Give a complete desciption (is 0 valid, what about 1, how to = decode...) "All modern versions of PGP MUST generate type 3 packets and SHOULD = decode type 2 packets." >- An eight-octet number that gives the ID of the public key that > the session key is encrypted to. > - A one-octet number giving the public-key algorithm used. Definition of values is where? >- A string of octets that is the encrypted session key. This > string takes up the remainder of the packet, but is not > explicitly counted. "...and is thus not explicitely counted." Intention is off... use "scalar" instead of "number" to keep term consistent in this = document. >5.2 Conventional Encrypted Session-Key Packets "5.2 Conventional Encrypted Session-Key Packets (Packet Tag 3)" What about tag 2? >This packet (tag 3) describes a session key that has been encrypted to a omit "(tag 3)" >secondary symmetric cipher. This allows a message to be encrypted to a >number of public keys, and also to one or more pass phrases. This packet >type is new, and is not generated by PGP 2.x or PGP 5.0. What about PGP 1.x or 0.x? >The body of this packet consists of: > - A one-octet version number. The current version is 4. Other versions, MUST, SHOULD... as above. > - A one-octet number describing the symmetric algorithm used. Definitions...where? > - A "string-to-key" object. This is described below. It is 2, 10, > or 11 octets long. > - The encrypted session key itself, which is decrypted with the > string-to-key object. Table Intention is off... >The string-to-key object has this format: > > Sure :) For other packet tags formattings needs to be chacket, headers should = add the tag value. and missing descriptions and value definitions = given >5.9 User-Name Packet > >A user-name packet is a counted string with a one-octet length. By >convention, it is an RFC 822 mail name, but there are no restrictions on = its >content. add tag value; what is "a (!) RFC mail name". Give an example. = Possibly the mailbox name is meant (as in a To:,CC:,BCC: spec. Or = "e-mail address"? >6. Constants > >This section describes the constants used in PGP Version 5.x. What about compatibility with previous (and future) versions?! Following tables need to be adapted to document standard. >7. Transferable Public Keys > > Public keys may transferred between PGP users. The essential elements > of a transferable public key are: Intention is off.. >8.1 Key Structures >Each signature certifies the RSA public key and the preceding UserID. >The RSA public key can have many UserIDs and each UserID can have >many signatures. Use either "User ID" or "UserID" for consistency. >8.2 Public Key Certificate Packet Structure > >To accommodate the addition of the subkey construction, a new >version of the public-key-certificate packet was created. Packets >with a version of '3' are still created for PGP keys that use RSA use either "version 3" or "version '3'" cnsistently. >public keys. For specifics on version 3 packets, see RFC 1991. >The terms and formatting used here are consistent with that RFC. "with that RFC"--> "with that document" >RSA Public Key Certificate Packet ("old format") > > a) packet structure field with CTB bits 5-2 =3D 0110 (2 or 3 bytes); > b) version number =3D 3 (1 byte); > c) time stamp of key creation (4 bytes); > d) validity period in days (0 means forever) (2 bytes); This table should be formatted according to previous table samples. And use octets instead of bytes, and two-octets and so on... >8.7 Future Formats > >Additional information on PGP formats is being provided to the public in >order for others to build compatible or complimentary systems that >support PGP. Eh? And: Add reference/bibliography and how to reach the author/working = group.... -END- =8A From owner-ietf-open-pgp Wed Aug 6 00:36:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA17022 for ietf-open-pgp-bks; Wed, 6 Aug 1997 00:36:37 -0700 (PDT) Received: from mail0.iij.ad.jp (mail0.iij.ad.jp [202.232.2.113]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id AAA17016 for ; Wed, 6 Aug 1997 00:36:32 -0700 (PDT) Received: from uucp1.iij.ad.jp (uucp1.iij.ad.jp [202.232.2.201]) by mail0.iij.ad.jp (8.8.5+2.7Wbeta5/3.5Wpl4-MAIL) with SMTP id QAA14187; Wed, 6 Aug 1997 16:40:51 +0900 (JST) Received: (from uucp@localhost) by uucp1.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id QAA02779; Wed, 6 Aug 1997 16:40:51 +0900 Received: from localhost by h2np.suginami.tokyo.jp (NX5.67c/IIJ-U1.2c) id AA04453; Wed, 6 Aug 97 16:33:01 +0900 Message-Id: <9708060733.AA04453@h2np.suginami.tokyo.jp> To: jude shabry Cc: ietf-open-pgp@imc.org Subject: Re: PGP Message Exchange Formats Internet Draft In-Reply-To: Your message of "Wed, 30 Jul 1997 17:02:34 MST." <19970731000235.11138.qmail@peace.netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Wed, 06 Aug 1997 16:33:00 +0900 From: Hironobu Suzuki Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >From Opening Message. > - new cipher suites (elliptic curve, other symmetric ciphers) and > cipher identifiers >From Internet Draft >6. Constants >* 6.1 Public Key Algorithms >* 6.4 Hash Algorithms I'd like to know to contact a person to get new chiper identifier. -- Hironobu SUZUKI Independent Software Consultant Tel: +81-3-5310-7303 Fax: +81-3-5382-7065 E-Mail: hironobu@h2np.suginami.tokyo.jp 3-42-19-306, Nishiogi Kita, Suginami, Tokyo, 167, JAPAN. From owner-ietf-open-pgp Wed Aug 6 09:23:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA23977 for ietf-open-pgp-bks; Wed, 6 Aug 1997 09:23:15 -0700 (PDT) Received: from merit.edu (merit.edu [198.108.1.42]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA23973 for ; Wed, 6 Aug 1997 09:23:11 -0700 (PDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm054-21.dialip.mich.net [141.211.6.159]) by merit.edu (8.8.6/8.8.5) with SMTP id MAA19919 for ; Wed, 6 Aug 1997 12:27:29 -0400 (EDT) Date: Wed, 6 Aug 97 14:51:12 GMT From: "William Allen Simpson" Message-ID: <6413.wsimpson@greendragon.com> To: ietf-open-pgp@imc.org Subject: content tag, format, terminology Sender: owner-ietf-open-pgp@imc.org Precedence: bulk There is a general problem with inconsistent terminology. I suggest that "octet" be changed everywhere to "byte", with a short section defining byte. Here's what I use: 1.1. Terminology In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC-2119]. byte An 8-bit quantity; also known as "octet" in standardese. ==== The term "packet" is simply wrong. A packet is a link-layer term. I suggest that "packet" be changed everywhere to "element", which would be consistent with other sections of the draft, including section titles using element. ==== And then there is the problem of the "cipher type byte", which does not define a cipher, and which contains a "tag". Please change the name to "Content Tag Byte", which should not be too hard. Many of the possible combinations of the CTB are not legal, or are never generated. The draft is confusing. A better organization would be a simple tabular list of the legal values and formats of the CTB. Here's what I suggest: hex element length version === ======= ====== ======= 00..83 Reserved 84 Public-Key-Encrypted Session-Key 1-byte 2.3.x 85 Public-Key-Encrypted Session-Key 2-byte 2.6.x 86..87 Reserved 88 Signature 1-byte 2.3.x 89 Signature 2-byte 2.6.x 8A..93 Reserved 94 Secret-Key (etc.) ..C0 Reserved C1 Public-Key-Encrypted Session-Key n-byte 5.0.x C2 Signature n-byte 5.0.x (etc.) Reserved. A CTB MUST NOT have a tag with this value. ==== And that n-byte length definition needs work. Very hard to understand. Worse, it is really rather ugly. Why have the 0..191 1-byte variant? Why not start with 2-byte length for everything? Are we really encouraging smaller than 256-bit moduli? OK, I suppose we are stuck with 0..191 for compatibility. But the next step should be changed. After all, you are bringing this to the IETF for standardization; the IETF will have change control. That power of two variant should be tossed. Is it ever used? In this case, I recommend that the stepping be this: hex decimal length formula === ======= ====== ======= 00..BF to 191 1-byte 0 .. 191 C0..EF to 239 2-byte ((b[1] - 192) * 256) + b[2] + 192 aka b[1..2] - 2**15 - 2**14 + 192 aka b[1..2] - 48,960 aka 192 .. 16,575 F0..FB to 251 3-byte b[1..3] - 2**23 - 2**22 - 2**21 - 2**20 + 16,576 aka 16,576 .. 1,065,151 aka much too much for IP FC..FF to 255 reserved WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ietf-open-pgp Wed Aug 6 11:21:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA25541 for ietf-open-pgp-bks; Wed, 6 Aug 1997 11:21:57 -0700 (PDT) Received: from hobbes.orl.lmco.com (hobbes.orl.lmco.com [141.240.192.100]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA25537 for ; Wed, 6 Aug 1997 11:21:53 -0700 (PDT) Date: Wed, 6 Aug 1997 14:25:37 -0400 (EDT) From: "A. Padgett Peterson P.E. Information Security" To: wsimpson@greendragon.com CC: ietf-open-pgp@imc.org Message-Id: <970806142537.20202033@hobbes.orl.lmco.com> Subject: RE: content tag, format, terminology Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > byte An 8-bit quantity; also known as "octet" in > standardese. Just a loint of paw but a byte is not always 8 bits though this is the common assumption today. If you asked an IBMer in 1981, the answer was 9 bits. To a Baudot type it would be five bits. The original definition was "that number of bits required to define an alphanumeric character" (including some punctuation) so varied by platform. Now if you wish to define it as such, that is fine however "octet" is the correct and specific term for eight bits. Warmly, Padgett From owner-ietf-open-pgp Wed Aug 6 11:32:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA25651 for ietf-open-pgp-bks; Wed, 6 Aug 1997 11:32:41 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA25647 for ; Wed, 6 Aug 1997 11:32:36 -0700 (PDT) Received: from [205.180.136.74] (pgp74.pgp.com [205.180.136.74]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id LAA03384; Wed, 6 Aug 1997 11:36:49 -0700 (PDT) Message-Id: <199708061836.LAA03384@fusebox.pgp.com> Subject: RE: content tag, format, terminology Date: Wed, 6 Aug 97 11:37:25 -0700 x-sender: noah@mail.pgp.com x-mailer: Claris Emailer 2.0v2, June 6, 1997 From: Noah Salzman To: "A. Padgett Peterson P.E. Information Security" , cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk A. Padgett Peterson P.E. Information Security (PADGETT@hobbes.orl.lmco.com) wrote this on 8/6/97 11:25 AM: >Just a loint of paw but a byte is not always 8 bits though this is >the common assumption today. If you asked an IBMer in 1981, the answer >was 9 bits. To a Baudot type it would be five bits. > >The original definition was "that number of bits required to define >an alphanumeric character" (including some punctuation) so varied by >platform. > >Now if you wish to define it as such, that is fine however "octet" is the >correct and specific term for eight bits. Since you brought it up, here is a little more info on byte length from: http://nightflight.com/foldoc/ (The Free Online Dictionairy of Computing) ------------------- byte A component in the machine data hierarchy usually larger than a bit and smaller than a word; now most often eight bits and the smallest addressable unit of storage. A byte typically holds one character. A byte may be 9 bits on 36-bit computers. Some older architectures used "byte" for quantities of 6 or 7 bits, and the PDP-10 and IBM 7030 supported "bytes" that were actually bitfields of 1 to 36 (or 64) bits! These usages are now obsolete, and even 9-bit bytes have become rare in the general trend toward power-of-2 word sizes. The term was coined by Werner Buchholz in 1956 during the early design phase for the IBM Stretch computer. It was a mutation of the word "bite" intended to avoid confusion with "bit". In 1962 he described it as "a group of bits used to encode a character, or the number of bits transmitted in parallel to and from input-output units". The move to an 8-bit byte happened in late 1956, and this size was later adopted and promulgated as a standard by the System/360 operating system (announced April 1964). James S. Jones adds: I am sure I read in some historical brochure by IBM some 15-20 years ago that BYTE was an acronym that stood for "Bit asYnchronous Transmission E__?__" which related to width of the bus between the Stretch CPU and its CRT-memory (prior to Core). See also nybble, octet. From owner-ietf-open-pgp Wed Aug 6 11:51:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA25839 for ietf-open-pgp-bks; Wed, 6 Aug 1997 11:51:15 -0700 (PDT) Received: from doorstop.cs.auckland.ac.nz (root@doorstop.cs.auckland.ac.nz [130.216.35.3]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA25828 for ; Wed, 6 Aug 1997 11:51:10 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.33.9]) by doorstop.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id GAA09943; Thu, 7 Aug 1997 06:54:43 +1200 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <87089371903111>; Thu, 7 Aug 1997 06:55:19 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: PADGETT@hobbes.orl.lmco.com Subject: RE: content tag, format, terminology Cc: ietf-open-pgp@imc.org Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Thu, 7 Aug 1997 06:55:19 (NZST) Message-ID: <87089371903111@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >>byte An 8-bit quantity; also known as "octet" in >> standardese. > >Just a loint of paw but a byte is not always 8 bits though this is >the common assumption today. If you asked an IBMer in 1981, the answer >was 9 bits. To a Baudot type it would be five bits. I knew someone was going to come up with this... in reply I'll post a classic flame of this sort of thing from Markus Kuhn. Followups to... well, somewhere else I guess. Peter. >Newsgroups: comp.text.sgml,comp.std.internat >From: mskuhn@cip.informatik.uni-erlangen.de (Markus Kuhn) >Subject: Silly ISO terminology (was: UTF) >Date: Tue, 11 Apr 1995 10:02:09 GMT > >I know very well that UTF means > > Universal Multiple-Octet Coded Character Set Transformation Format. > >Some ISO committees have a real talent for effective anti-marketing by >introducing lots of abbreviations which only support the common theory that >some ISO standards have been written by little green monsters from outer space >in order to confuse normal human beings and prepare them for the big invasion. >Who can remember 'Universal Multiple-Octet Coded Character Set Transformation >Format' easily without checking the standard? > >Why means UCS 'Universal Multiple-Octet Coded Character Set' and not simply >much easier to remember 'Universal Character Set'? Why do we use strange >terminology like 'octet' while today every 10-year old kid learns at school >that 'byte' means 'an 8-bit binary number used in computers to store >information'. Why use many character set standards still the extremely exotic >08/15 notation for bytes (sorry, octets ;-) instead of the hexadecimal notatio >used by everyone else all over the world. > >Markus Peter. From owner-ietf-open-pgp Wed Aug 6 14:35:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA27486 for ietf-open-pgp-bks; Wed, 6 Aug 1997 14:35:51 -0700 (PDT) Received: from merit.edu (merit.edu [198.108.1.42]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA27482 for ; Wed, 6 Aug 1997 14:35:47 -0700 (PDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm036-25.dialip.mich.net [141.211.7.67]) by merit.edu (8.8.6/8.8.5) with SMTP id RAA26290 for ; Wed, 6 Aug 1997 17:40:07 -0400 (EDT) Date: Wed, 6 Aug 97 21:23:23 GMT From: "William Allen Simpson" Message-ID: <6414.wsimpson@greendragon.com> To: ietf-open-pgp@imc.org Subject: Re: terminology Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Folks, I've also been around since Baudot days, and am familiar with at least some of the different sized historic bytes. That's why I think we should specifically define the meaning in a terminology section. As opposed to the 9 in 36 mentioned, another of the byte sizes is 6 in 36 and 6 in 60 for the CDC 3000 and 6000 series respectively. I used octet throughout PPP specifications, to be least confusing to folks reading ISO, CCITT and IETF documents in parallel. I use byte in other venues. In any case, the terms should be well defined, and cognizant of the intended reader. The problem that I raised was that _both_ byte and octet are used in the same document. Pick one. Be consistent and readable. Thank you. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ietf-open-pgp Thu Aug 7 13:28:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA29388 for ietf-open-pgp-bks; Thu, 7 Aug 1997 13:28:31 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA29374 for ; Thu, 7 Aug 1997 13:28:24 -0700 (PDT) Received: from [194.0.130.21] (tent-194-0-130-21.campsite.hip97.nl [194.0.130.21]) by fusebox.pgp.com (8.8.5/8.8.5) with ESMTP id NAA20604; Thu, 7 Aug 1997 13:32:29 -0700 (PDT) X-Sender: jon@mail.pgp.com (Unverified) Message-Id: In-Reply-To: <199708061836.LAA03384@fusebox.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Aug 1997 13:32:21 -0700 To: Noah Salzman , "A. Padgett Peterson P.E. Information Security" , From: Jon Callas Subject: RE: content tag, format, terminology Cc: Sender: owner-ietf-open-pgp@imc.org Precedence: bulk As the person who is guilty of using the word "octet" in the draft, and who encouraged others to do the same, I suppose I should say why I did. When I was lobbying for it, I said, "'octet' is the politically correct way to say 'byte'" and gave pretty much the same explanations that Padgett and others did. Once, long ago, there were other size bytes than the ones that ones we're all used to. I agree that it's an odd term, and one that makes a lot of people just wonder. I can think of a couple of easy solutions. One is that we put in a paragraph explaining that an octet is a PC byte (in more ways than one). Another is that we change all the uses of "octet" to "byte" and put in a paragraph explaining that for this documentation, when we say "byte" we mean an eight-bit byte, the type that many other standards call an octet. Either is fine with me. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 From owner-ietf-open-pgp Thu Aug 7 14:01:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA03669 for ietf-open-pgp-bks; Thu, 7 Aug 1997 14:01:41 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA03653 for ; Thu, 7 Aug 1997 14:01:36 -0700 (PDT) Received: from [194.0.130.21] (tent-194-0-130-21.campsite.hip97.nl [194.0.130.21]) by fusebox.pgp.com (8.8.5/8.8.5) with ESMTP id OAA21052; Thu, 7 Aug 1997 14:05:57 -0700 (PDT) X-Sender: jon@mail.pgp.com (Unverified) Message-Id: In-Reply-To: <9708060733.AA04453@h2np.suginami.tokyo.jp> References: Your message of "Wed, 30 Jul 1997 17:02:34 MST." <19970731000235.11138.qmail@peace.netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Aug 1997 13:47:37 -0700 To: Hironobu Suzuki , jude shabry From: Jon Callas Subject: Re: PGP Message Exchange Formats Internet Draft Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 12:33 AM -0700 8/6/97, Hironobu Suzuki said: I'd like to know to contact a person to get new chiper identifier. That might as well be me. As we progress with making PGP a standard, we'll be setting up a way to do that. If you don't need it right away, let the list know what you want, and it will get on our to-do list. If you need it right away, we'll get you one ASAP. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 From owner-ietf-open-pgp Thu Aug 7 18:34:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA19953 for ietf-open-pgp-bks; Thu, 7 Aug 1997 18:34:53 -0700 (PDT) Received: from dfw-ix12.ix.netcom.com (dfw-ix12.ix.netcom.com [206.214.98.12]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA19949 for ; Thu, 7 Aug 1997 18:34:48 -0700 (PDT) Received: (from smap@localhost) by dfw-ix12.ix.netcom.com (8.8.4/8.8.4) id UAA02573; Thu, 7 Aug 1997 20:37:33 -0500 (CDT) Received: from ffd-ca1-20.ix.netcom.com(205.186.177.52) by dfw-ix12.ix.netcom.com via smap (V1.3) id sma002433; Thu Aug 7 20:36:26 1997 Message-Id: <3.0.2.32.19970807183309.0069cb34@popd.netcruiser> X-Sender: JonWienk@popd.netcruiser X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Thu, 07 Aug 1997 18:33:09 -0700 To: Jon Callas , jude shabry , coderpunks@toad.com From: Jonathan Wienke Subject: Re: PGP Message Exchange Formats Internet Draft Cc: ietf-open-pgp@imc.org In-Reply-To: References: <9708060733.AA04453@h2np.suginami.tokyo.jp> <19970731000235.11138.qmail@peace.netris.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=====_Eudora-PGP-Plugin6131==_"; micalg=pgp-md5; protocol="application/pgp-signature"; PGPFormat="PGPMIME-signed" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --=====_Eudora-PGP-Plugin6131==_ Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Instead of having a 1-byte cipher identifier, I would like to see a 4 byte text identifier for ciphers and hashes, so IDEA could be designated by "IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it much easier for PGP to support numerous algorithms, and multiple encryption. Perhaps each algorithm could be implemented as a plug-in, so that encrypting a message with triple-DES, IDEA, and then something cooked up in your basement would be easily implemented. At 01:47 PM 8/7/97 -0700, Jon Callas wrote: >At 12:33 AM -0700 8/6/97, Hironobu Suzuki said: > > > I'd like to know to contact a person to get new chiper identifier. > >That might as well be me. As we progress with making PGP a standard, we'll >be setting up a way to do that. If you don't need it right away, let the >list know what you want, and it will get on our to-do list. If you need it >right away, we'll get you one ASAP. > > Jon > > > >----- >Jon Callas jon@pgp.com >Chief Scientist 555 Twin Dolphin Drive >Pretty Good Privacy, Inc. Suite 570 >(415) 596-1960 Redwood Shores, CA 94065 > > > > Jonathan Wienke What part of "the right of the people to keep and bear Arms, shall not be infringed" is too hard to understand? (From 2nd Amendment, U.S. Constitution) PGP 2.6.2 RSA Key Fingerprint: 7484 2FB7 7588 ACD1 3A8F 778A 7407 2928 DSS/D-H Key Fingerprint: 3312 6597 8258 9A9E D9FA 4878 C245 D245 EAA7 0DCC Public keys available at pgpkeys.mit.edu. PGP encrypted e-mail preferred. US/Canadian Windows 95/NT or Mac users: Get Eudora Light + PGP 5.0 for free at http://www.eudora.com/eudoralight/ Get PGP 5.0 for free at http://bs.mit.edu:8001/pgp-form.html Commercial version of PGP 5.0 and related products at http://www.pgp.com Eudora + PGP = Free, Convenient Communication Privacy Go postal! Write your mommy a letter! --=====_Eudora-PGP-Plugin6131==_ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 MessageID: BK3k88TlTLlw6MnckWGSX6X4duur9lYb iQEVAwUBM+p5HmrcIxe8e5eNAQHkZAgAwHzyn5B+P2p/WC5oKqEJaWFNXG4JvYGc 06hQFfGQBz6sqheoZQ7Tz4DWXJQ4ztjATmVlNmJoyhhl2l8qQoL0dHAGUTovH/Kq XbEX72Avy505Y6PWj2DVuJeTE98sW6WV9kfPXYsTLIww6cstOw/K6h8+N5/Xs+C2 EId7MD/hVIRZCPPQmkaKl4uoBKsyDfDx3C5kHV7Wv27JKTMESo7dga4zTAz99021 5ZaqW2Be6vtM+tPZpEZWr0ZOnvDz55E7KuskVRpzczNEoAZRzuSjZmRrH8QQNCyu HktRjT9ZuR3n/H1vFKKanrDCqufusRmheye+lxixLU9pVjVp+TGBKA== =FybT -----END PGP SIGNATURE----- --=====_Eudora-PGP-Plugin6131==_-- From owner-ietf-open-pgp Thu Aug 7 19:56:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA20403 for ietf-open-pgp-bks; Thu, 7 Aug 1997 19:56:53 -0700 (PDT) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA20396 for ; Thu, 7 Aug 1997 19:56:46 -0700 (PDT) Received: (adam@localhost) by homeport.org (8.8.5/8.6.9) id WAA08984; Thu, 7 Aug 1997 22:48:50 -0400 (EDT) From: Adam Shostack Message-Id: <199708080248.WAA08984@homeport.org> Subject: Re: PGP Message Exchange Formats Internet Draft In-Reply-To: <3.0.2.32.19970807183309.0069cb34@popd.netcruiser> from Jonathan Wienke at "Aug 7, 97 06:33:09 pm" To: JonWienk@ix.netcom.com (Jonathan Wienke) Date: Thu, 7 Aug 1997 22:48:49 -0400 (EDT) Cc: jon@pgp.com, jude@pgp.com, coderpunks@toad.com, ietf-open-pgp@imc.org X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk And RIPEMD-160 would be indicated how? Having length byte, text field may well be overkill. So I'd suggest that a one byte ID with everything in an include file makes writing code easier, and doesn't need to change the presentation. Adam Jonathan Wienke wrote: | Instead of having a 1-byte cipher identifier, I would like to see a 4 byte | text identifier for ciphers and hashes, so IDEA could be designated by | "IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it much | easier for PGP to support numerous algorithms, and multiple encryption. | Perhaps each algorithm could be implemented as a plug-in, so that | encrypting a message with triple-DES, IDEA, and then something cooked up in | your basement would be easily implemented. | | At 01:47 PM 8/7/97 -0700, Jon Callas wrote: | >At 12:33 AM -0700 8/6/97, Hironobu Suzuki said: | > | > | > I'd like to know to contact a person to get new chiper identifier. | > | >That might as well be me. As we progress with making PGP a standard, we'll | >be setting up a way to do that. If you don't need it right away, let the | >list know what you want, and it will get on our to-do list. If you need it | >right away, we'll get you one ASAP. | > | > Jon | > | > | > | >----- | >Jon Callas jon@pgp.com | >Chief Scientist 555 Twin Dolphin Drive | >Pretty Good Privacy, Inc. Suite 570 | >(415) 596-1960 Redwood Shores, CA 94065 | > | > | > | > | | Jonathan Wienke | | What part of "the right of the people to keep and bear Arms, shall not be | infringed" is too hard to understand? (From 2nd Amendment, U.S. Constitution) | | PGP 2.6.2 RSA Key Fingerprint: 7484 2FB7 7588 ACD1 3A8F 778A 7407 2928 | DSS/D-H Key Fingerprint: 3312 6597 8258 9A9E D9FA 4878 C245 D245 EAA7 0DCC | Public keys available at pgpkeys.mit.edu. PGP encrypted e-mail preferred. | | US/Canadian Windows 95/NT or Mac users: | Get Eudora Light + PGP 5.0 for free at http://www.eudora.com/eudoralight/ | Get PGP 5.0 for free at http://bs.mit.edu:8001/pgp-form.html | Commercial version of PGP 5.0 and related products at http://www.pgp.com | Eudora + PGP = Free, Convenient Communication Privacy | | Go postal! Write your mommy a letter! [application/pgp-signature is not supported, skipping...] -- "It is seldom that liberty of any kind is lost all at once." -Hume From owner-ietf-open-pgp Thu Aug 7 20:42:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA20672 for ietf-open-pgp-bks; Thu, 7 Aug 1997 20:42:11 -0700 (PDT) Received: from brahma.sics.se (brahma.sics.se [193.10.66.43]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA20668 for ; Thu, 7 Aug 1997 20:42:07 -0700 (PDT) Received: from anhur.sics.se by brahma.sics.se (8.7.3/SICS) with ESMTP id FAA13272; Fri, 8 Aug 1997 05:45:56 +0200 (MET DST) Received: from assaris.sics.se by anhur.sics.se (8.7.3/SICS-client) with ESMTP id FAA11954; Fri, 8 Aug 1997 05:45:55 +0200 (MET DST) Received: (from assar@localhost) by assaris.sics.se (8.8.5/8.8.5) id FAA10905; Fri, 8 Aug 1997 05:46:45 +0200 (MET DST) To: Jonathan Wienke Cc: Jon Callas , jude shabry , coderpunks@toad.com, ietf-open-pgp@imc.org Subject: Re: PGP Message Exchange Formats Internet Draft References: <9708060733.AA04453@h2np.suginami.tokyo.jp> <19970731000235.11138.qmail@peace.netris.org> <3.0.2.32.19970807183309.0069cb34@popd.netcruiser> Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 08 Aug 1997 05:46:39 +0200 In-Reply-To: Jonathan Wienke's message of Thu, 07 Aug 1997 18:33:09 -0700 Message-ID: <5lafite3q8.fsf@assaris.sics.se> Lines: 15 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jonathan Wienke writes: > Instead of having a 1-byte cipher identifier, I would like to see a 4 byte > text identifier for ciphers and hashes, so IDEA could be designated by > "IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it much > easier for PGP to support numerous algorithms, and multiple encryption. Do you really see a new for more than 256 algoritms? > Perhaps each algorithm could be implemented as a plug-in, so that > encrypting a message with triple-DES, IDEA, and then something cooked up in > your basement would be easily implemented. Having one byte doesn't stop you for implementing plug-ins. /assar From owner-ietf-open-pgp Thu Aug 7 20:38:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA20629 for ietf-open-pgp-bks; Thu, 7 Aug 1997 20:38:48 -0700 (PDT) Received: from clipper.webcc.net (clipper.webcc.net [207.67.206.2]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA20625 for ; Thu, 7 Aug 1997 20:38:44 -0700 (PDT) Received: from [207.67.207.179] (burns.idio.com [207.67.207.179]) by clipper.webcc.net (8.8.5/8.6.9) with ESMTP id UAA31383; Thu, 7 Aug 1997 20:38:54 -0700 X-Sender: mclow@webcc.net Message-Id: In-Reply-To: <199708080248.WAA08984@homeport.org> References: <3.0.2.32.19970807183309.0069cb34@popd.netcruiser> from Jonathan Wienke at "Aug 7, 97 06:33:09 pm" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Aug 1997 20:39:31 -0700 To: Adam Shostack , JonWienk@ix.netcom.com (Jonathan Wienke) From: Marshall Clow Subject: Re: PGP Message Exchange Formats Internet Draft Cc: jon@pgp.com, jude@pgp.com, coderpunks@toad.com, ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 7:48 PM -0700 8/7/97, Adam Shostack wrote: >Jonathan Wienke wrote: >| Instead of having a 1-byte cipher identifier, I would like to see a 4 byte >| text identifier for ciphers and hashes, so IDEA could be designated by >| "IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it much >| easier for PGP to support numerous algorithms, and multiple encryption. >| Perhaps each algorithm could be implemented as a plug-in, so that >| encrypting a message with triple-DES, IDEA, and then something cooked up in >| your basement would be easily implemented. >| >And RIPEMD-160 would be indicated how? Having length byte, text field >may well be overkill. So I'd suggest that a one byte ID with >everything in an include file makes writing code easier, and doesn't >need to change the presentation. > As much a fan of 4 byte identifiers as I am, I agree with Adam here. We aren't going to see 2 billion or so cipher ids. However, I can envision a day when we have more than 256 cipher IDs. Two bytes, please (or octets, if you prefer) -- Marshall Marshall Clow Aladdin Systems "In Washington DC, officials from the White House, federal agencies and Congress say regulations may be necessary to promote a free-market system." -- CommunicationsWeek International April 21, 1997 From owner-ietf-open-pgp Fri Aug 8 01:46:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA22359 for ietf-open-pgp-bks; Fri, 8 Aug 1997 01:46:26 -0700 (PDT) Received: from smtp2.xs4all.nl (smtp2.xs4all.nl [194.109.6.52]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id BAA22355 for ; Fri, 8 Aug 1997 01:46:20 -0700 (PDT) Received: from bofh.cdg.openlinksw.com (evrl.xs4all.nl [194.109.62.84]) by smtp2.xs4all.nl (8.8.6/XS4ALL) with ESMTP id JAA07717; Fri, 8 Aug 1997 09:46:04 +0200 (CEST) Received: from bofh.cdg.openlinksw.com (localhost [127.0.0.1]) by bofh.cdg.openlinksw.com (8.8.5/8.8.5) with ESMTP id JAA29738; Fri, 8 Aug 1997 09:39:29 +0200 Message-Id: <199708080739.JAA29738@bofh.cdg.openlinksw.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Assar Westerlund cc: Jonathan Wienke , Jon Callas , jude shabry , coderpunks@toad.com, ietf-open-pgp@imc.org Subject: Re: PGP Message Exchange Formats Internet Draft In-reply-to: Your message of "08 Aug 1997 05:46:39 +0200." <5lafite3q8.fsf@assaris.sics.se> From: Cees de Groot Reply-To: cg@pobox.com X-Face: 1j+F?Ev#1:D^z&gV(.0-?V29b9N0TUse)^#M(9ZBP]t'lJuQa1:uft+lv&iEo*#Ca1ecS5& b\pen"Um#bydQ|6~@#JbdMQQ>.F0P"ocvT'c,uBlqmm<&FHs`rzi"8|8IR8=)NW`no:=5A$n@H$!ly bNoO=rU;[-z"Z.0v-e[QqfKt$xm7DI`%FdV@r!>mK6bt$$8Cg-TNa+KQu2!CT&94tT[j1 nVb-JK2o_d"F4\byhPUBsg7[3$q3*N[fij)C:=||+S9qudo7:s!8C#ak7RXSbp7Qz{Y"-57]DfvlO* fh X-PGP-Id: 4F018825/2048 X-PGP-Fingerprint: 5653C0DDECE4359DFFDDB8F7A7970789 X-URL: http://pobox.com/~cg Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Aug 1997 09:39:29 +0200 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk assar@sics.se said: > Do you really see a new for more than 256 algoritms? Some people didn't see a need for more than 640k, either... For this one byte, you step from likely exhaustion of your cypher-id space to very unlikely exhaustion. If people pick this up, start experimenting, etcetera - yes I can envision more than 256 algorithms. 65536, on the other hand, should be enough. -- Cees de Groot http://pobox.com/~cg Principal Consultant OpenLink Software http://www.openlinksw.com/ From owner-ietf-open-pgp Fri Aug 8 03:55:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id DAA24748 for ietf-open-pgp-bks; Fri, 8 Aug 1997 03:55:49 -0700 (PDT) Received: from bar.pilsnet.sunet.se (bar.pilsnet.sunet.se [192.36.125.14]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id DAA24744 for ; Fri, 8 Aug 1997 03:55:43 -0700 (PDT) Received: (from bygg@localhost) by bar.pilsnet.sunet.se (8.8.5/8.8.5) id MAA07551; Fri, 8 Aug 1997 12:59:40 +0200 (MET DST) Date: Fri, 8 Aug 1997 12:59:39 MET DST From: Johnny Eriksson To: coderpunks@toad.com Cc: ietf-open-pgp@imc.org Subject: Re: PGP Message Exchange Formats Internet Draft In-Reply-To: Your message of 08 Aug 1997 05:46:39 +0200 Message-ID: Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Assar wrote: > Jonathan Wienke writes: > > Instead of having a 1-byte cipher identifier, I would like to see a 4 byte > > text identifier for ciphers and hashes, so IDEA could be designated by > > "IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it much > > easier for PGP to support numerous algorithms, and multiple encryption. > > Do you really see a new for more than 256 algoritms? No, but... 256 is a rather low value for infinity, no matter what you are using it for. 2^32 is a low value for the max number of IP addresses, but it looked more than enough a number of years ago. We might not see a need for more than 256 types right now, but it's still stupid to restrict things. And having a 4-byte menmonic name is cute. > /assar --Johnny From owner-ietf-open-pgp Fri Aug 8 04:39:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id EAA25062 for ietf-open-pgp-bks; Fri, 8 Aug 1997 04:39:57 -0700 (PDT) Received: from sinfonix.rz.tu-clausthal.de (6kMfuR+d/Do2nNDfXfLoQoBjOX8mUSZZ@sinfonix.rz.tu-clausthal.de [139.174.253.19]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id EAA25058 for ; Fri, 8 Aug 1997 04:39:50 -0700 (PDT) Received: from pct56 (esca2.pe.tu-clausthal.de [139.174.155.236]) by sinfonix.rz.tu-clausthal.de (8.8.7/8.8.7) with SMTP id MAA26312; Fri, 8 Aug 1997 12:38:09 +0200 (MET DST) Message-Id: <1.5.4.16.19970808103739.253fb452@pop.rz.tu-clausthal.de> X-Sender: pehw@pop.rz.tu-clausthal.de X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 Aug 1997 12:37:39 +0200 To: ietf-open-pgp@imc.org From: Hagen Wollert Subject: Re: PGP Message Exchange Formats Internet Draft Cc: coderpunks@toad.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hello to all, at 09:39 08.08.1997 +0200 Cees de Groot (>) wrote: >assar@sics.se said: >> Do you really see a new for more than 256 algoritms? > >Some people didn't see a need for more than 640k, either... > >For this one byte, you step from likely exhaustion of your cypher-id space to >very unlikely exhaustion. If people pick this up, start experimenting, >etcetera - yes I can envision more than 256 algorithms. 65536, on the other >hand, should be enough. Well, here are my 2 cents to this context: One of the most wide-spread and commonly used graphic-file-format ist the well-known Tif-format: It has been designed to be able to imply all future needs by specifying them in tags when needed with the effect that programs are downward-compatible. Thus it now lasts for at least 5 years which is a relatively long period compared the lifetime of hard- & software. I think one should reserve at least 4 bytes ( each consisting of 8 bits :-) ) of data thus being able to roughly specify algorithms in ASCII-digits ( ( each consisting of 7 bits preceded by a '0' ;-) ) or directly being able to use 2**28 = 268,435,456 or even 2**31 = 2,147,483,648 different algorithms ( each or the first byte beginning with a '1' ). This is even more than any key-sub-space commonly used by beginners. Best regards, Hagen -- _____________________________________________________________________ Hagen Wollert h.wollert@tu-clausthal.de PGPed E-Mail welcome - public key available on most key-servers 2048/BBAF99CD MD5: 11 AD A2 70 67 0A 32 CA 34 D8 F0 CE 67 8A B7 A1 From owner-ietf-open-pgp Fri Aug 8 05:13:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id FAA25205 for ietf-open-pgp-bks; Fri, 8 Aug 1997 05:13:54 -0700 (PDT) Received: from exub.ex.ac.uk (exub.ex.ac.uk [144.173.6.72]) by mail.proper.com (8.8.5/8.7.3) with SMTP id FAA25201 for ; Fri, 8 Aug 1997 05:13:47 -0700 (PDT) Received: from aba@dialup16.ex.ac.uk [144.173.6.216] by exub via ESMTP (NAA05745); Fri, 8 Aug 1997 13:17:00 +0100 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id NAA00311; Fri, 8 Aug 1997 13:16:42 +0100 Date: Fri, 8 Aug 1997 13:16:42 +0100 Message-Id: <199708081216.NAA00311@server.test.net> From: Adam Back To: cg@pobox.com CC: assar@sics.se, jon@pgp.com, jude@pgp.com, coderpunks@toad.com, ietf-open-pgp@imc.org In-reply-to: <199708080739.JAA29738@bofh.cdg.openlinksw.com> (message from Cees de Groot on Fri, 08 Aug 1997 09:39:29 +0200) Subject: algorithm ID encodings & terminology (was Re: PGP Message Exchange Formats Internet Draft) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk knightPhlight writes: > "640k should be more than enough memory for anybody." - Bill Gates Cees de Groot writes: > Some people didn't see a need for more than 640k, either... Uncanny, same message simultaneously. Anyway I side with knightPhlight -- 256 isn't enough, and 64k isn't enough either. Who knows what you'll need. Make it a string. It'll only cost you one byte (or nothing compared to Cees's call for 2 bytes). As another thing what happened to the unix philosphy of human readable file formats? Or at least file formats that you can reasonably pick apart with a hex editor? Why are PGP so keen to hand huffman encode everything? (single bit fields, 1 byte identifier, variable length of length fields etc.) PRZ wrote PGP 1.0 for DOS first, perhaps this is why ... Personally I would start over and use some thing that would cause pgp2.x to give up gracefully as the first byte. I can grant something for cleartext signatures perhaps, but other than that it's hardly an issue. If pgp are concerned about size at this nit-picking hand huffman encoding level: they made the wrong choice with El Gamal, they would've saved space with straight Diffie-Hellman, and not had to generate so many random numbers as a bonus. (A pgp employee who I won't name admitted in the past when this issue was raised, oh well, it's only a few bytes). Another thing while I'm at it: The constant use of Diffie-Hellman to refer to El-Gamal is misleading. Is seems to get referred to as "Diffie-Hellman" with occasional note that actually they mean El-Gamal, "a variant of Diffie-Hellman." Is this mis-nomenclature motivated by a belief that more people will have heard of Diffie-Hellman and hence get a warm fuzzy feeling or something? It's El-Gamal, damn it! (re hand huffman encoding fun -- it's something I have practice at, my sig is an implementation of RSA in perl and dc, which has been hand compressed in such a way that it still functions -- even gzip can't wring much out of it now -- actualy it gets bigger if you consider that it is already seven bit clean). Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Fri, 8 Aug 1997 05:53:56 -0700 (PDT) Received: from sulphur.osf.org (sulphur.camb.opengroup.org [130.105.1.123]) by postman.opengroup.org (8.8.6/8.8.6) with ESMTP id IAA24678; Fri, 8 Aug 1997 08:57:56 -0400 (EDT) Received: (from rsalz@localhost) by sulphur.osf.org (8.7.5/8.7.3) id IAA02598; Fri, 8 Aug 1997 08:57:49 -0400 (EDT) Date: Fri, 8 Aug 1997 08:57:49 -0400 (EDT) From: Rich Salz Message-Id: <199708081257.IAA02598@sulphur.osf.org> To: assar@sics.se Subject: Re: PGP Message Exchange Formats Internet Draft Cc: coderpunks@toad.com, ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > Do you really see a new for more than 256 algoritms? Some people (and incredibly big manufacturers of computers) are inclined to consider 40bitRC4 a different algorithm from 128bitRC4. So the answer to your question is "yes, trivially." /r$ From owner-ietf-open-pgp Fri Aug 8 06:31:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA25969 for ietf-open-pgp-bks; Fri, 8 Aug 1997 06:31:25 -0700 (PDT) Received: from brahma.sics.se (brahma.sics.se [193.10.66.43]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA25965 for ; Fri, 8 Aug 1997 06:31:20 -0700 (PDT) Received: from anhur.sics.se by brahma.sics.se (8.7.3/SICS) with ESMTP id PAA06860; Fri, 8 Aug 1997 15:35:47 +0200 (MET DST) Received: from assaris.sics.se by anhur.sics.se (8.7.3/SICS-client) with ESMTP id PAA14444; Fri, 8 Aug 1997 15:35:46 +0200 (MET DST) Received: (from assar@localhost) by assaris.sics.se (8.8.5/8.8.5) id PAA11389; Fri, 8 Aug 1997 15:36:37 +0200 (MET DST) To: coderpunks@toad.com, ietf-open-pgp@imc.org Subject: PGP cipher tags References: <199708081257.IAA02598@sulphur.osf.org> Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 08 Aug 1997 15:36:35 +0200 In-Reply-To: Rich Salz's message of Fri, 8 Aug 1997 08:57:49 -0400 (EDT) Message-ID: <5liuxgdcf0.fsf@assaris.sics.se> Lines: 46 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk - Do we really need more than 256 algorithms _in PGP_? There are and will be lots of new algorithms. Even more if we take into consideration the key size used. But will/should all these really be used and specified in PGP? - Do we have to change the existing spec (and implementations) that use 8 bits for specifying the algorithm? These are the existing algorithms from section 6 of draft-ietf-pgp-formats00.txt: ---------------------------------------------------------------------- 6. Constants This section describes the constants used in PGP Version 5.x. 6.1 Public Key Algorithms 1 - RSA 16 - Diffie-Helman, El Gamal variant 17 - DSS (Digital Signature Algorithm) 6.2 Symmetric Key Algorithms 0 - Plaintext 1 - IDEA 2 - Triple-DES (DES-EDE, 168 bit key) 3 - CAST5 (128 bit key) 6.3 Compression Algorithms 0 - Uncompressed 1 - ZIP 6.4 Hash Algorithms 1 - MD5 2 - SHA-1 ? - RIPE-MD/160 ---------------------------------------------------------------------- - If there's a need for more than 256 algorithms, how should these be coded? In binary or in ascii? Fixed length or variable length? /assar From owner-ietf-open-pgp Fri Aug 8 06:51:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA26128 for ietf-open-pgp-bks; Fri, 8 Aug 1997 06:51:37 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA26124 for ; Fri, 8 Aug 1997 06:51:33 -0700 (PDT) Received: by brickwall.ceddec.com id <32258>; Fri, 8 Aug 1997 09:55:47 -0400 Date: Fri, 8 Aug 1997 09:56:48 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: coderpunks@toad.com cc: ietf-open-pgp@imc.org Subject: Re: PGP Message Exchange Formats Internet Draft In-Reply-To: Message-Id: <97Aug8.095547edt.32258@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Thu, 7 Aug 1997, Marshall Clow wrote: > At 7:48 PM -0700 8/7/97, Adam Shostack wrote: > >Jonathan Wienke wrote: > >| Instead of having a 1-byte cipher identifier, I would like to see a 4 byte > >| text identifier for ciphers and hashes, so IDEA could be designated by > >| "IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it much > >| easier for PGP to support numerous algorithms, and multiple encryption. > >| Perhaps each algorithm could be implemented as a plug-in, so that > >| encrypting a message with triple-DES, IDEA, and then something cooked up in > >| your basement would be easily implemented. > >| > >And RIPEMD-160 would be indicated how? Having length byte, text field > >may well be overkill. So I'd suggest that a one byte ID with > >everything in an include file makes writing code easier, and doesn't > >need to change the presentation. > > > As much a fan of 4 byte identifiers as I am, I agree with Adam here. > We aren't going to see 2 billion or so cipher ids. > > However, I can envision a day when we have more than 256 cipher IDs. > > Two bytes, please (or octets, if you prefer) You will need more than one byte, unless PGP wants to insist that only their version of CFB is used for the internal complication. There is now a CBC(?) version of CAST, and the other variants deserve either another chain/feedback byte, or we simply need a bigger integer to store it. Just go to Applied Cryptography and start counting algorithms and then ways to make the algorithms more complex, and multiply. But before this goes off on a tangent, PGP 5.0 (at least the source code I have seen) isn't modular in the sense of having a dlopen(alg) call, and I, for one, would not like to see 1,000 algorithms defined because no two implementations would work together, or the program would need to be larger than most hard drives. This issue itself should limit the number of algorithms to 256 or less. --- reply to tzeruch - at - ceddec - dot - com --- From owner-ietf-open-pgp Fri Aug 8 08:53:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA27368 for ietf-open-pgp-bks; Fri, 8 Aug 1997 08:53:39 -0700 (PDT) Received: from nova.botz.org (root@jbotz.wco.com [209.21.31.7]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA27361 for ; Fri, 8 Aug 1997 08:53:30 -0700 (PDT) Received: from nova.botz.org (localhost [127.0.0.1]) by nova.botz.org (8.8.5/8.8.5) with ESMTP id IAA28689; Fri, 8 Aug 1997 08:54:12 -0700 Message-Id: <199708081554.IAA28689@nova.botz.org> X-Mailer: exmh version 2.0delta 6/3/97 To: tzeruch@ceddec.com From: Jurgen Botz Cc: coderpunks@toad.com, ietf-open-pgp@imc.org Subject: Re: PGP Message Exchange Formats Internet Draft In-Reply-To: Your message of "Fri, 08 Aug 1997 09:56:48 EDT." <97Aug8.095547edt.32258@brickwall.ceddec.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1707635456P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 08 Aug 1997 08:54:12 -0700 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --==_Exmh_-1707635456P Content-Type: text/plain; charset=us-ascii tzeruch@ceddec.com wrote: > and I, for one, would not like to see 1,000 algorithms defined because no > two implementations would work together, or the program would need to be > larger than most hard drives. It may seem that way, but if you think about it... cryptographic algorithms are usually /tiny/ pieces of code. Often less than 1k of object code but even if it's 5k that's still only 5MB for 1000 of 'em... a lot smaller than MS Word or other such. And besides, algorithms could be linked in dynamically at run-time. --==_Exmh_-1707635456P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3i iQCVAwUBM+tBI0b1AZ4jlS4BAQExgwP/Zacn8R831QlTRGtMgz+PTJjy9YSLhG5J eoDaBMSoPt9ZINi49PukpCp0RX+7E1+j/wwRXgOlXnvs1ALH5DDr25y4WyzGHLP5 2QVJxtqVdv9v8PdkpAWMwDy5OA7KxrZlronCD7IkEwSYosgsr0t/JJdez2XunIZG Srpxv8qb298= =tNri -----END PGP MESSAGE----- --==_Exmh_-1707635456P-- From owner-ietf-open-pgp Fri Aug 8 12:04:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA28905 for ietf-open-pgp-bks; Fri, 8 Aug 1997 12:04:24 -0700 (PDT) Received: from charon.MIT.EDU (brnstndkramden.acf.nyu.edu@CHARON.MIT.EDU [18.70.0.224]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA28900 for ; Fri, 8 Aug 1997 12:04:20 -0700 (PDT) Received: (from warlord@localhost) by charon.MIT.EDU (8.7.6/2.3JIK) id OAA02893; Fri, 8 Aug 1997 14:59:27 -0400 To: tzeruch@ceddec.com Cc: coderpunks@toad.com, ietf-open-pgp@imc.org Subject: Modular algorithms in PGP 5.0 (was Re: PGP Message Exchange Formats Internet Draft) References: <97Aug8.095547edt.32257@brickwall.ceddec.com> From: Derek Atkins Date: 08 Aug 1997 14:59:25 -0400 In-Reply-To: tzeruch@ceddec.com's message of Fri, 8 Aug 1997 09:56:48 -0400 Message-ID: Lines: 30 X-Mailer: Gnus v5.2.37/Emacs 19.34 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Umm, I'm not sure what code you've seen, but if you look in lib/pgp/crypt/cipher.c(*) and lib/pgp/crypt/hash.c(*), you will find functions like "pgpGetCipherByNumber()", "pgpGetCipherByName()", "pgpGetHashByNumber()", and "pgpGetHashByName()". These could _EASILY_ be re-implemented as dlopen() calls. -dere (*) These files are from a VERY old source code tree, circa October 1996. The file names and function names may have changed between then and now. YMMV. tzeruch@ceddec.com writes: > But before this goes off on a tangent, PGP 5.0 (at least the source > code I have seen) isn't modular in the sense of having a dlopen(alg) call, > and I, for one, would not like to see 1,000 algorithms defined because no > two implementations would work together, or the program would need to be > larger than most hard drives. > > This issue itself should limit the number of algorithms to 256 or less. > > --- reply to tzeruch - at - ceddec - dot - com --- > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-open-pgp Fri Aug 8 12:18:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA29095 for ietf-open-pgp-bks; Fri, 8 Aug 1997 12:18:27 -0700 (PDT) Received: from hobbes.orl.lmco.com (hobbes.orl.lmco.com [141.240.192.100]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA29086 for ; Fri, 8 Aug 1997 12:18:22 -0700 (PDT) Date: Fri, 8 Aug 1997 15:22:19 -0400 (EDT) From: "A. Padgett Peterson P.E. Information Security" To: ietf-open-pgp@imc.org CC: coderpunks@toad.com Message-Id: <970808152219.20203308@hobbes.orl.lmco.com> Subject: Re: PGP Message Exchange Formats Internet Draft Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >And RIPEMD-160 would be indicated how? Having length byte, text field >may well be overkill. So I'd suggest that a one byte ID with >everything in an include file makes writing code easier, and doesn't >need to change the presentation. While four bytes might be overkill, I suspect that a single byte with only 255 possibilities (assume 0 means plaintext) may well be insufficient. At least a word (16 bits/ 65535 possibilities) would seem more appropriate particularly with so many varients of each (RC4-40, 56, 64, 128, ...). Some may recall that IBM felt that one nibble was sufficient to define all possible disk types in the CMOS in 1982 with Type 15 becoming a pointer to an extended table and 49 eventually becomming "define your own". A word is used in UNIX to define TCP protocols, in 1981 (RFC 793) 255 probably would have seemed adequate for that use also. Warmly, Padgett From owner-ietf-open-pgp Fri Aug 8 12:49:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA29433 for ietf-open-pgp-bks; Fri, 8 Aug 1997 12:49:16 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA29427 for ; Fri, 8 Aug 1997 12:49:12 -0700 (PDT) Received: by brickwall.ceddec.com id <32258>; Fri, 8 Aug 1997 15:53:36 -0400 Date: Fri, 8 Aug 1997 15:54:36 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: coderpunks@toad.com cc: ietf-open-pgp@imc.org Subject: Re: PGP Message Exchange Formats Internet Draft In-Reply-To: <199708081554.IAA28689@nova.botz.org> Message-Id: <97Aug8.155336edt.32258@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 8 Aug 1997, Jurgen Botz wrote: > tzeruch@ceddec.com wrote: > > and I, for one, would not like to see 1,000 algorithms defined because no > > two implementations would work together, or the program would need to be > > larger than most hard drives. > > It may seem that way, but if you think about it... cryptographic algorithms > are usually /tiny/ pieces of code. Often less than 1k of object code but > even if it's 5k that's still only 5MB for 1000 of 'em... a lot smaller than > MS Word or other such. And besides, algorithms could be linked in dynamically > at run-time. How large are the S-Boxes for DES and CAST? And what if 500 of the algorithms are simply variants of the above with different s-boxes? You also need key setup, which seems to be different for each algorithm. Linking them in dynamically doesn't shrink them, it simply scatters them among 500 DLLs or one giant DLL, and if the only use of that DLL is for PGP, it may as well be in the binary. I have shared libraries for SSLeay and have taken to convert my crypto code to use that instead, and even did the SSL for lynx in a generic proxy (works with GNUscape for emacs too), which ends up around 20K under Linux i386 for a full SSL server and client proxy that handles certificates. Of course PGP doesn't use any existing library for these functions, and Netscape has its own internal Crypto and Bignums to do SSL, and the OS internal stuff has another one... --- reply to tzeruch - at - ceddec - dot - com --- From owner-ietf-open-pgp Fri Aug 8 14:53:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA00501 for ietf-open-pgp-bks; Fri, 8 Aug 1997 14:53:51 -0700 (PDT) Received: from exub.ex.ac.uk (exub.ex.ac.uk [144.173.6.72]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA00497 for ; Fri, 8 Aug 1997 14:53:42 -0700 (PDT) Received: from aba@dialup19.ex.ac.uk [144.173.6.219] by exub via ESMTP (WAA07051); Fri, 8 Aug 1997 22:57:44 +0100 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id UAA01720; Fri, 8 Aug 1997 20:21:41 +0100 Date: Fri, 8 Aug 1997 20:21:41 +0100 Message-Id: <199708081921.UAA01720@server.test.net> From: Adam Back To: assar@sics.se CC: coderpunks@toad.com, ietf-open-pgp@imc.org In-reply-to: <5liuxgdcf0.fsf@assaris.sics.se> (message from Assar Westerlund on 08 Aug 1997 15:36:35 +0200) Subject: extensibility & code bloat (Re: PGP cipher tags) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Assar Westerlund writes: > - Do we really need more than 256 algorithms _in PGP_? > > [...] > 6.2 Symmetric Key Algorithms > > 0 - Plaintext > 1 - IDEA > 2 - Triple-DES (DES-EDE, 168 bit key) ^^^^^^^^^^^^^^^^^^^^ I think this answers your question: yes. There are lots of modes, key sizes, etc. And a variable length algorithm description string costs almost nothing and offers ultimate flexibility, so why not do it. > - If there's a need for more than 256 algorithms, how should these be > coded? In binary or in ascii? Fixed length or variable length? ASCII, variable length. I was kind of toying with the idea of creating a human readable formal grammar which describes algorithm combinations. Might save multiple entries for DES (DES CBC, DES CFB, DES OFB, 3DES-EDE, etc.,etc), and would allow you to "implement" a chosen mode just by specifying what mode you wanted DES, and how to combine that to mutliple key DES. Anyone for outer-CBC 5DES? Plus how to deal with short last blocks, how you want the IV constructed etc. PGP seems pretty big as it is. This could stop reinvention of the wheel, and hence reduce more code bloat when new algorithms are added by providing a more flexible plug in. You provide the code for the encryption and decryption of one block (ie ECB style). You then describe the mode you want using the grammar, and you're done. If you want a new mode, or new short end block treatment, you add one of those too. So if I get bored one day and go implement that lot, your 2 byte field might be pretty painful for me. But a variable length string would be a handy way for me not to confuse implementations without this ability, without having to design whole new formats. Don't worry about the above example ... but please lets have variable length fields for some future proofing of the message layout. PGP message spec already went through one set of fudging to work around some pgp2.x message spec limitations which made it difficult to extend in such a way as not to cause earlier implementations to barf, lets use the experience to avoid doing the same thing with pgp3. Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Fri, 8 Aug 1997 23:43:27 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.33.9]) by doorstop.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id SAA13218; Sat, 9 Aug 1997 18:46:56 +1200 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <87110925527324>; Sat, 9 Aug 1997 18:47:35 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: aba@dcs.ex.ac.uk Subject: Re: extensibility & code bloat (Re: PGP cipher tags) Cc: coderpunks@toad.com, ietf-open-pgp@imc.org Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Sat, 9 Aug 1997 18:47:35 (NZST) Message-ID: <87110925527324@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Death rays from Mars made Adam Back write: >>Assar Westerlund writes: >> - If there's a need for more than 256 algorithms, how should these be >> coded? In binary or in ascii? Fixed length or variable length? >ASCII, variable length. > >I was kind of toying with the idea of creating a human readable formal >grammar which describes algorithm combinations. Might save multiple entries >for DES (DES CBC, DES CFB, DES OFB, 3DES-EDE, etc.,etc), and would allow you >to "implement" a chosen mode just by specifying what mode you wanted DES, and >how to combine that to mutliple key DES. Anyone for outer-CBC 5DES? This gets ugly real quick. I thought of doing this for cryptlib, something like: cryptAlgorithm = 3des { mode = cbc, padding = PKCS#5, noKeys = 2 } cryptAlgorithm = safer { mode = cfb, keysize = 128, useSaferSK = TRUE } (and even wrote most of a parser for it) but dropped it for a number of reasons: 1. The code to parse this starts to get scary, because when a (say) dlopen()'d module registers a new algorithm it also has to register a grammar to allow its config settings to be parsed. Some of the parsing code may have to reside in the crypto module, because the general parser won't be aware of every conceivable type of config option and setting in advance. 2. This doesn't work well under Windows where config options are held in the registry and might be administered by third-party software (for example a company might want to have a centrally-enforced policy of "No RSA until 2000", which would be controlled by the administrator setting the signAlgorithm to ElGamal on all the machines in the domain). It's easy enough to do this if it's an integer, you look up what you want in a table and set the "signAlgorithm" key to 17 (or whatever ElGamal is), but if you have to build up a huge long text string it gets complicated. It gets even more complex if the policy is "We allow anything nonpatented", because a check like "( id == 17 || id == 18 )" is a lot easier to perform than one involving arbitrarily-formatted strings which can contain God knows what. 3. Virtually noone will ever use this capability. I know from feedback from cryptlib users that virtually noone uses the InitEx() functions (which allow you to specify special-case parameters), and I can't see this as being any different from PGP. What you'd be doing is adding a lot of extra complications with little overall gain (in fact the added complexity is probably going to cause more problems than it's worth, not only because of the overhead in managing it but because allowing people to specify 7DES/CFB-47 will almost guarantee that anything they produce can't be decrypted by anyone else on earth). Peter. From owner-ietf-open-pgp Sat Aug 9 01:53:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA03869 for ietf-open-pgp-bks; Sat, 9 Aug 1997 01:53:42 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id BAA03865 for ; Sat, 9 Aug 1997 01:53:38 -0700 (PDT) Received: from [194.0.130.16] (tent-194-0-130-16.campsite.hip97.nl [194.0.130.16]) by fusebox.pgp.com (8.8.5/8.8.5) with ESMTP id BAA13503; Sat, 9 Aug 1997 01:57:21 -0700 (PDT) X-Sender: jon@mail.pgp.com Message-Id: In-Reply-To: <199708081216.NAA00311@server.test.net> References: <199708080739.JAA29738@bofh.cdg.openlinksw.com> (message from Cees de Groot on Fri, 08 Aug 1997 09:39:29 +0200) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Aug 1997 06:56:14 -0700 To: Adam Back , cg@pobox.com From: Jon Callas Subject: Re: algorithm ID encodings & terminology (was Re: PGP Message Exchange Formats Internet Draft) Cc: assar@sics.se, jude@pgp.com, coderpunks@toad.com, ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 5:16 AM -0700 8/8/97, Adam Back said: Why are PGP so keen to hand huffman encode everything? I concur completely. I once got so fed up with this habit that I tromped around the office singing, "Every bit is sacred / Every bit is great / When a bit is wasted / Phil gets quite irate." Consider this to be one of the prime things to correct. Personally, I think that numbers should never (well, hardly ever) be smaller than 32 bits. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 From owner-ietf-open-pgp Sat Aug 9 01:54:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA03878 for ietf-open-pgp-bks; Sat, 9 Aug 1997 01:54:15 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id BAA03874 for ; Sat, 9 Aug 1997 01:54:11 -0700 (PDT) Received: from [194.0.130.16] (tent-194-0-130-16.campsite.hip97.nl [194.0.130.16]) by fusebox.pgp.com (8.8.5/8.8.5) with ESMTP id BAA13501; Sat, 9 Aug 1997 01:56:57 -0700 (PDT) X-Sender: jon@mail.pgp.com Message-Id: In-Reply-To: <199708080248.WAA08984@homeport.org> References: <3.0.2.32.19970807183309.0069cb34@popd.netcruiser> from Jonathan Wienke at "Aug 7, 97 06:33:09 pm" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Aug 1997 06:45:08 -0700 To: Adam Shostack , JonWienk@ix.netcom.com (Jonathan Wienke) From: Jon Callas Subject: Re: PGP Message Exchange Formats Internet Draft Cc: jude@pgp.com, coderpunks@toad.com, ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk There's already a constant for RIPE-MD/160. It may have gotten slipped from that draft. There will be another draft once we're back from Europe. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 From owner-ietf-open-pgp Sat Aug 9 07:53:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA07111 for ietf-open-pgp-bks; Sat, 9 Aug 1997 07:53:26 -0700 (PDT) Received: from dfw-ix15.ix.netcom.com (dfw-ix15.ix.netcom.com [206.214.98.15]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA07107 for ; Sat, 9 Aug 1997 07:53:22 -0700 (PDT) Received: (from smap@localhost) by dfw-ix15.ix.netcom.com (8.8.4/8.8.4) id JAA26469; Sat, 9 Aug 1997 09:56:51 -0500 (CDT) Received: from ffd-ca1-10.ix.netcom.com(205.186.177.42) by dfw-ix15.ix.netcom.com via smap (V1.3) id sma026418; Sat Aug 9 09:55:59 1997 Message-Id: <3.0.2.32.19970809075908.00688c34@popd.netcruiser> X-Sender: JonWienk@popd.netcruiser X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Sat, 09 Aug 1997 07:59:08 -0700 To: coderpunks@toad.com, ietf-open-pgp@imc.org From: Jonathan Wienke Subject: Re: extensibility & code bloat (Re: PGP cipher tags) In-Reply-To: <87110925527324@cs26.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=====_Eudora-PGP-Plugin19044==_"; micalg=pgp-md5; protocol="application/pgp-signature"; PGPFormat="PGPMIME-signed" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --=====_Eudora-PGP-Plugin19044==_ Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 06:47 PM 8/9/97, Peter Gutmann wrote: > >Death rays from Mars made Adam Back write: > >>>Assar Westerlund writes: >>> - If there's a need for more than 256 algorithms, how should these be >>> coded? In binary or in ascii? Fixed length or variable length? >>ASCII, variable length. >> >>I was kind of toying with the idea of creating a human readable formal >>grammar which describes algorithm combinations. Might save multiple entries >>for DES (DES CBC, DES CFB, DES OFB, 3DES-EDE, etc.,etc), and would allow you >>to "implement" a chosen mode just by specifying what mode you wanted DES, and >>how to combine that to mutliple key DES. Anyone for outer-CBC 5DES? > >This gets ugly real quick. I thought of doing this for cryptlib, something >like: > > cryptAlgorithm = 3des { mode = cbc, padding = PKCS#5, noKeys = 2 } > cryptAlgorithm = safer { mode = cfb, keysize = 128, useSaferSK = TRUE } > >(and even wrote most of a parser for it) but dropped it for a number of >reasons: > >1. The code to parse this starts to get scary, because when a (say) dlopen()'d >module registers a new algorithm it also has to register a grammar to allow >its config settings to be parsed. Some of the parsing code may have to reside >in the crypto module, because the general parser won't be aware of every >conceivable type of config option and setting in advance. On the other hand, if you have an ASCII string descriptor for each algorithm permutation (such as "3DES-3Key-CFB") and a set of plug-ins that each handle a set of permutations, (one does "RC4-128", "RC4-64", and "RC4-40", another does "IDEA-PGP" and "IDEA-CFB", another does "FEAL-NSA", etc.) then writing code that invokes the correct plug-in and passes it the descriptor string and other data is fairly straightforward. Given the average public key size seems to be about 1024 bits (128 bytes/octets), there is certainly room for a string descriptor for the encryption algorithm/mode, the session key, the signature algorithm/mode, and the ID/fingerprint of the signature key in the public key encrypted portion of the message header. For example: 9 bytes: "IDEA-PGP" (length + 8 data bytes) 17 bytes: IDEA session key (length + 16 data bytes) 8 bytes: "ElGamal" (length + 7 data bytes) 21 bytes: signature key fingerprint (length + 20 data bytes) 55 bytes total. This would still leave 73 bytes for random padding or other purposes. Jonathan Wienke What part of "the right of the people to keep and bear Arms, shall not be infringed" is too hard to understand? (From 2nd Amendment, U.S. Constitution) PGP 2.6.2 RSA Key Fingerprint: 7484 2FB7 7588 ACD1 3A8F 778A 7407 2928 DSS/D-H Key Fingerprint: 3312 6597 8258 9A9E D9FA 4878 C245 D245 EAA7 0DCC Public keys available at pgpkeys.mit.edu. PGP encrypted e-mail preferred. US/Canadian Windows 95/NT or Mac users: Get Eudora Light + PGP 5.0 for free at http://www.eudora.com/eudoralight/ Get PGP 5.0 for free at http://bs.mit.edu:8001/pgp-form.html Commercial version of PGP 5.0 and related products at http://www.pgp.com Eudora + PGP = Free, Convenient Communication Privacy Go postal! Write your mommy a letter! --=====_Eudora-PGP-Plugin19044==_ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 MessageID: Wxi6k0HFfahdrh9DOl+x2shR0azG7aHJ iQEVAwUBM+yGH2rcIxe8e5eNAQGsPwf/cNmldxrW0SePBPNDqDUvQqFKX9XLq/H3 yK4IxY5y7oqBpD47QnlXLl87MVrFBS1WCgSU6VLH2A4eQMhHllSNPJjCc2jhVbSt 2aTXCQTaJnU6zNH2TDSueUb61B42VSaorEXrYrw4/tF2wVpqIoc2swMAZ4qJOXdK 5kgx7PPMxQk2ehzc2XL+drmXnr/OC2JuM3qwYuvgPk32ieVo16QYcsqI+RamwEUI r1iLLCTJTb7I16QJ2vmCOB4FWR5A83GMoFvOq3X3/niH21+0hdawadLzSCc2KImf d3ulEWCST5RlE3Oca8hufvAde1eUJOO0+IhB5YkEmQ0L++F9RGUi8A== =FPf/ -----END PGP SIGNATURE----- --=====_Eudora-PGP-Plugin19044==_-- From owner-ietf-open-pgp Sat Aug 9 09:13:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA07786 for ietf-open-pgp-bks; Sat, 9 Aug 1997 09:13:23 -0700 (PDT) Received: from exub.ex.ac.uk (exub.ex.ac.uk [144.173.6.72]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA07781 for ; Sat, 9 Aug 1997 09:13:15 -0700 (PDT) Received: from aba@dialup18.ex.ac.uk [144.173.6.218] by exub via ESMTP (RAA09006); Sat, 9 Aug 1997 17:17:29 +0100 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id NAA00229; Sat, 9 Aug 1997 13:20:34 +0100 Date: Sat, 9 Aug 1997 13:20:34 +0100 Message-Id: <199708091220.NAA00229@server.test.net> From: Adam Back To: pgut001@cs.auckland.ac.nz CC: coderpunks@toad.com, ietf-open-pgp@imc.org In-reply-to: <87110925527324@cs26.cs.auckland.ac.nz> (pgut001@cs.auckland.ac.nz) Subject: Re: extensibility & code bloat (Re: PGP cipher tags) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Peter Gutmann writes: > Death rays from Mars made Adam Back write: > >I was kind of toying with the idea of creating a human readable formal > >grammar which describes algorithm combinations. > > This gets ugly real quick. I thought of doing this for cryptlib, something > like: > > cryptAlgorithm = 3des { mode = cbc, padding = PKCS#5, noKeys = 2 } > cryptAlgorithm = safer { mode = cfb, keysize = 128, useSaferSK = TRUE } > > (and even wrote most of a parser for it) but dropped it for a number of > reasons: > > 1. The code to parse this starts to get scary, because when a (say) > dlopen()'d module registers a new algorithm it also has to register > a grammar to allow its config settings to be parsed. Some of the > parsing code may have to reside in the crypto module, because the > general parser won't be aware of every conceivable type of config > option and setting in advance. Yup. Interesting that you gave it a go also. I was thinking of using perl... the eval function plus a bit of hacking around would mean that the extension language was almost perl code, and you'd pass it through various filtering rules to make good perl code before evaling it. As you say you'd have the extensions signed by people, and users could base their trust on that in a distributed fashion. If PRZ signs El-Gamal and CAST well then a lot of people would use that recommendation. But if I'm paranoid, and the random number generator is good enough to not become the weak point, I can request R = RANDOM( sizeof(M) ), C = 5DES(M) xor 3IDEA(M XOR R) (With 2x expansion of message size -- the simple way to have something as good as the better of two ciphers -- now if someone finds a new type of attack which means 3IDEA turns out to be naff, I'm OK so long as 5DES doesn't fall. All presuming the RANDOM function is good enough). I also consider that it would be interesting for the sender to be able to request replies using the senders chosen cipher set. > 3. Virtually noone will ever use this capability. I know from > feedback from cryptlib users that virtually noone uses the InitEx() > functions (which allow you to specify special-case parameters), and > I can't see this as being any different from PGP. Sure. It's not a main stream issue -- PGP isn't going to get involved in all the extra complexity because it's not commercially justifiable. Was just pleading the case to make it flexible so that there was room for expasion in un-predicted directions. Adam From owner-ietf-open-pgp Sat Aug 9 16:31:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA11702 for ietf-open-pgp-bks; Sat, 9 Aug 1997 16:31:27 -0700 (PDT) Received: from abby.skypoint.net (abby.skypoint.net [199.86.32.252]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA11694 for ; Sat, 9 Aug 1997 16:31:18 -0700 (PDT) Received: from bit3.com (uucp@localhost) by abby.skypoint.net (8.8.5/alexis 2.7) with SMTP id SAA01922; Sat, 9 Aug 1997 18:23:44 -0500 (CDT) Received: by bit3.com (Smail3.1.28.1 #19) id m0wxKmj-000UOdC; Sat, 9 Aug 97 18:19 CDT Date: Sat, 9 Aug 1997 18:19:00 -0500 (CDT) From: brianh@risky.bit3.com To: Adam Back cc: assar@sics.se, coderpunks@toad.com, ietf-open-pgp@imc.org Subject: Re: extensibility & code bloat (Re: PGP cipher tags) In-Reply-To: <199708081921.UAA01720@server.test.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Have people considered seperating the mode from cipher used? Each cipher would have a small number of functions and constants to define (functions: expand_key and encrypt_block (which would also decrypt block), and constants: key_length, expanded_key_length, and block_length). The next layer would be multi-encryption (for instance, 3-EDE). The layer above that would be mode (CBC, code book, etc). The encoding would then be something like: CBC-3EDE-DES With the three parts each going to the three layers. This would keep code bloat down (among other things, like making experimentation easier). There would be a slight cost in performance (a couple of extra function calls, and the dropping of some possible optimizations- like dropping the initial/final permutations between rounds of 3DES). Thoughts? Brian Any resemblance of these opinions to the opinions of Brian Hurt, Bit 3 Computer Corporation, or any individual living or dead is purely coincidental. From owner-ietf-open-pgp Sun Aug 10 09:17:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA17668 for ietf-open-pgp-bks; Sun, 10 Aug 1997 09:17:59 -0700 (PDT) Received: from merit.edu (merit.edu [198.108.1.42]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA17664 for ; Sun, 10 Aug 1997 09:17:55 -0700 (PDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-09.dialip.mich.net [141.211.7.145]) by merit.edu (8.8.6/8.8.5) with SMTP id MAA24713 for ; Sun, 10 Aug 1997 12:22:30 -0400 (EDT) Date: Sat, 9 Aug 97 20:13:50 GMT From: "William Allen Simpson" Message-ID: <6428.wsimpson@greendragon.com> To: ietf-open-pgp@imc.org Subject: purpose: evolution or revolution Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Gentlefolk, it appears to me that there are rather different goals for some of the participants. Some only desire a good documentation of what is already there. Many are interested in making minor modifications to clean it up a bit. Still others seem ready to completely redo and expand the PGP format, using 16 bit fields where there were 8 bits, or variable length, or even entire grammars. When the BoF is held, please discuss this issue. ==== For myself, put me in the middle -- minor modifications, every bit is sacred, and past and present interoperability reigns supreme. Let SPKI handle variable length everything. A different effort. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ietf-open-pgp Sun Aug 10 17:04:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA19969 for ietf-open-pgp-bks; Sun, 10 Aug 1997 17:04:07 -0700 (PDT) Received: from punt-1.mail.demon.net (relay-13.mail.demon.net [194.217.242.137]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA19965 for ; Sun, 10 Aug 1997 17:04:02 -0700 (PDT) Received: from marui.demon.co.uk ([194.222.113.225]) by punt-1.mail.demon.net id aa1113326; 11 Aug 97 0:54 BST Received: (from mark@localhost) by marui (8.6.9/8.6.9) id WAA00487; Sun, 10 Aug 1997 22:35:27 GMT Date: Sun, 10 Aug 1997 22:35:24 +0000 From: Mark Grant Reply-To: Mark Grant Subject: Re: algorithm ID encodings & terminology (was Re: PGP Message Exchange Formats Internet Draft) To: Adam Back cc: cg@pobox.com, assar@sics.se, jon@pgp.com, jude@pgp.com, coderpunks@toad.com, ietf-open-pgp@imc.org In-Reply-To: <199708081216.NAA00311@server.test.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 8 Aug 1997, Adam Back wrote: > Why are PGP so keen to hand huffman encode everything? Presumably to increase security; longer identifiers give an attacker more known -- or easily guessed -- plaintext. While I consider a brute-force attack on PGP infeasible for a long time I'm not sure that we should be giving away more known plaintext than we need to. (Excuse my ignorance if we're not talking about the same identifiers; I haven't read the PGP format documentation for some time). Mark |-----------------------------------------------------------------------| |Mark Grant M.A., U.L.C. EMAIL: mark@unicorn.com | |WWW: http://www.unicorn.com/ MAILBOT: bot@unicorn.com | |-----------------------------------------------------------------------| From owner-ietf-open-pgp Mon Aug 11 01:28:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA23306 for ietf-open-pgp-bks; Mon, 11 Aug 1997 01:28:38 -0700 (PDT) Received: from gatekeeper1.telekom.de (gatekeeper1.telekom.de [194.25.15.6]) by mail.proper.com (8.8.5/8.7.3) with SMTP id BAA23302 for ; Mon, 11 Aug 1997 01:28:32 -0700 (PDT) Received: from mailgate1.telekom.de by gatekeeper2.telekom.de; (5.65v3.2/1.1.8.2/02Aug95-0132PM) id AA31244; Mon, 11 Aug 1997 10:13:46 +0200 Received: from Q9F47.dmst02.telekom.de by mailgate1.telekom.de; (5.65v3.2/1.1.8.2/02Aug95-1122AM) id AA29216; Mon, 11 Aug 1997 10:13:45 +0200 Received: from ac8717hye12006 (isparkes@q9f47.dmst02.telekom.de) by q9f47.dmst02.telekom.de (8.8.3/3) with SMTP id JAA30929; Mon, 11 Aug 1997 09:41:39 +0200 Message-Id: <3.0.2.32.19970811101249.006a69d4@q9f47.dmst02.telekom.de> X-Sender: isparkes@q9f47.dmst02.telekom.de X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Mon, 11 Aug 1997 10:12:49 +0200 To: Johnny Eriksson From: Ian Sparkes Subject: Re: PGP Message Exchange Formats Internet Draft Cc: ietf-open-pgp@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 12:59 08.08.97 DST, you wrote: >Assar wrote: > >> Jonathan Wienke writes: >> > Instead of having a 1-byte cipher identifier, I would like to see a 4 byte >> > text identifier for ciphers and hashes, so IDEA could be designated by >> > "IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it much >> > easier for PGP to support numerous algorithms, and multiple encryption. >> >> Do you really see a new for more than 256 algoritms? > >No, but... 256 is a rather low value for infinity, no matter what you >are using it for. 2^32 is a low value for the max number of IP addresses, >but it looked more than enough a number of years ago. > >We might not see a need for more than 256 types right now, but it's still >stupid to restrict things. And having a 4-byte menmonic name is cute. I'm happy to see 1 byte, 4 bytes, any length you want, but let's focus on the essential point here, and that is compatibility. There is no point in sending a message out into the world that the spooks can't read, when the recipient can't read it either because he doesn't happen to have PGP 5.123.2 (or whatever) on his machine. The choice of algorithm is largely a matter of opinion and politics, and everyone has his own personal favorite. If we *really* open this up, then it won't be long before there are an infinite number of possibilities. (Perhaps we'll even see Rot13 in there - it's fast and someone out there somewhere loves it.) Perhaps it is possible to come up with some form of 'plugin' architecture, allowing the enthusiasts to think up any number of options for themselves, but keeping the core clean and compatible. > >> /assar > >--Johnny > > From owner-ietf-open-pgp Mon Aug 11 01:41:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA23441 for ietf-open-pgp-bks; Mon, 11 Aug 1997 01:41:12 -0700 (PDT) Received: from grinch.whoville.leftbank.com (grinch.leftbank.com [139.167.128.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id BAA23437 for ; Mon, 11 Aug 1997 01:41:07 -0700 (PDT) Received: from zax.whoville.leftbank.com by grinch.whoville.leftbank.com via smtpd (for mail.proper.com [206.86.127.224]) with SMTP; 11 Aug 1997 08:45:36 UT Received: from max.whoville.leftbank.com (max.whoville.leftbank.com [139.167.32.1]) by zax.leftbank.com (8.7.5/8.7.3/LeftBank-1.1/http://www.leftbank.com/) with SMTP id EAA29078; Mon, 11 Aug 1997 04:47:13 -0400 (EDT) Received: from lbo.leftbank.com ([192.31.227.130]) by max.whoville.leftbank.com via smtpd (for zax.whoville.leftbank.com [139.167.32.33]) with SMTP; 11 Aug 1997 08:45:34 UT Received: from Laptop-static-rodney.ietf.de (Laptop-static-rodney.ietf.de [195.27.194.28]) by lbo.leftbank.com (8.8.5/8.7.3/http://www.LeftBank.Com) with SMTP id EAA22655; Mon, 11 Aug 1997 04:45:33 -0400 (EDT) Message-Id: <3.0.1.32.19970811104139.008132f0@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 11 Aug 1997 10:41:39 -0400 To: ietf-open-pgp@imc.org From: Rodney Thayer Subject: comments on message exchange draft [not encodings!] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I have some comments -- -- I assume this iteration of this draft is intended to document current practice so I assume we're not opening up the body for massive changes, regardless of their brilliance. -- this document seems to duplicate some of the information in Stallings/etc.' existing PGP RFC. I don't see why. -- the name contents should be more clearly spelled out. For example the fact you can do 'comment' [with viacrypt but not with pgp 5 :-(] should be more clearly described. -- there should be more detailed CRC reference information. If you can suck in the Base 64 prose for the n-th time in the IETF draft world, you can suck in the CRC information. -- Rodney Thayer Sable Technology +1 617 332 7292 -- From owner-ietf-open-pgp Mon Aug 11 05:34:32 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id FAA27122 for ietf-open-pgp-bks; Mon, 11 Aug 1997 05:34:32 -0700 (PDT) Received: from hobbes.orl.lmco.com (hobbes.orl.lmco.com [141.240.192.100]) by mail.proper.com (8.8.5/8.7.3) with SMTP id FAA27114 for ; Mon, 11 Aug 1997 05:34:27 -0700 (PDT) Date: Mon, 11 Aug 1997 8:38:07 -0400 (EDT) From: "A. Padgett Peterson P.E. Information Security" To: coderpunks@toad.com CC: ietf-open-pgp@imc.org Message-Id: <970811083807.20204005@hobbes.orl.lmco.com> Subject: Re: extensibility & code bloat (Re: PGP cipher tags) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Have come to the conclusion that and ASCIIZ string is the proper answer with 00h indicating either none or the end of the matter. This way it can be 1) Intelligible 2) If the vendor wants to use a single byte, they can (with reguistration) Since virtually all complilers include routines to handle ASCIIZ strings, handling would be easy. Wasn't that easy. Warmly, Padgett From owner-ietf-open-pgp Mon Aug 11 06:44:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA27695 for ietf-open-pgp-bks; Mon, 11 Aug 1997 06:44:19 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA27691 for ; Mon, 11 Aug 1997 06:44:15 -0700 (PDT) Received: by brickwall.ceddec.com id <32261>; Mon, 11 Aug 1997 09:49:00 -0400 Date: Mon, 11 Aug 1997 09:48:28 -0400 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars.ceddec.com To: Jon Callas cc: Adam Back , coderpunks@toad.com, ietf-open-pgp@imc.org Subject: Re: algorithm ID encodings & terminology (was Re: PGP Message Exchange Formats Internet Draft) In-Reply-To: Message-Id: <97Aug11.094900edt.32261@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 8 Aug 1997, Jon Callas wrote: > At 5:16 AM -0700 8/8/97, Adam Back said: > > Why are PGP so keen to hand huffman encode everything? > > I concur completely. I once got so fed up with this habit that I tromped > around the office singing, "Every bit is sacred / Every bit is great / When > a bit is wasted / Phil gets quite irate." > > Consider this to be one of the prime things to correct. Personally, I think > that numbers should never (well, hardly ever) be smaller than 32 bits. > > Jon You obviously were never an embedded systems programmer :). After you expand everything to need a 256K buffer, you can have the fun of coding PGP5 for the USR Palm Pilot :). --- reply to tzeruch - at - ceddec - dot - com --- From owner-ietf-open-pgp Mon Aug 11 06:48:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA27756 for ietf-open-pgp-bks; Mon, 11 Aug 1997 06:48:55 -0700 (PDT) Received: from sinfonix.rz.tu-clausthal.de (9CZtsTEIbGhUaiSL+VfTtmyLk/55V0hv@sinfonix.rz.tu-clausthal.de [139.174.253.19]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA27752 for ; Mon, 11 Aug 1997 06:48:50 -0700 (PDT) Received: from pct56 (esca2.pe.tu-clausthal.de [139.174.155.236]) by sinfonix.rz.tu-clausthal.de (8.8.7/8.8.7) with SMTP id PAA01615; Mon, 11 Aug 1997 15:53:14 +0200 (MET DST) Message-Id: <1.5.4.16.19970811135241.32efdc48@pop.rz.tu-clausthal.de> X-Sender: pehw@pop.rz.tu-clausthal.de X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Aug 1997 15:52:41 +0200 To: ietf-open-pgp@imc.org From: Hagen Wollert Subject: Re: PGP Message Exchange Formats Internet Draft Cc: coderpunks@toad.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hello to all, at 10:12 11.08.1997 +0200 Assar wrote: >[..] let's focus on >the essential point here, and that is compatibility. There is no point in >sending a message out into the world that the spooks can't read, when the >recipient can't read it either because he doesn't happen to have PGP >5.123.2 (or whatever) on his machine. I'd like to refer to te Tiff-format again: There surely might be comprehensive readers being able to read&write in many formats and I think the old standard (RSA/IDEA/MD5) and a set coping with the actual future standard (whatever it might be) should be read by all. Therefore slimmed versions might run on handheld systems with acceptable performance whereas versions reading and writing any known format will more memory or computing power when using longer keys. >The choice of algorithm is largely a >matter of opinion and politics, and everyone has his own personal favorite. >If we *really* open this up, then it won't be long before there are an >infinite number of possibilities. (Perhaps we'll even see Rot13 in there - >it's fast and someone out there somewhere loves it.) :-) I'm afraid for the moment we are at a point here it is to decide whether to imply anything into one comprehensive format (like Tiff) or have many formats parallel formats like a set of (Tiff, Gif, JPEG, TGA, BMP, PCX, etc.) with a whole lot of compatbility problems in the future. IMHO the first option should be given the choice. >Perhaps it is possible to come up with some form of 'plugin' architecture, >allowing the enthusiasts to think up any number of options for themselves, >but keeping the core clean and compatible. Yes, a plug-in-architecture might be the optimum. Especially there definitely will be future needs similar to those occurred today: DES is no longer considered secure and there definitely are problems with MD5. Who dares to estimate that factorizing large numbers won't be more easy within 10 years thus endangering RSA ? With an universal standard one would just have to change from RSA to anything else (Diffie-Hellman, El-Gamal or whatever yet to be developed) and still will provide downward compatibility. Read you, Hagen -- _____________________________________________________________________ Hagen Wollert h.wollert@tu-clausthal.de PGPed E-Mail welcome - public key available on most key-servers 2048/BBAF99CD MD5: 11 AD A2 70 67 0A 32 CA 34 D8 F0 CE 67 8A B7 A1 From owner-ietf-open-pgp Mon Aug 11 06:50:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA27774 for ietf-open-pgp-bks; Mon, 11 Aug 1997 06:50:09 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA27770 for ; Mon, 11 Aug 1997 06:50:05 -0700 (PDT) Received: by brickwall.ceddec.com id <32260>; Mon, 11 Aug 1997 09:54:48 -0400 Date: Mon, 11 Aug 1997 09:55:18 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: brianh@risky.bit3.com cc: Adam Back , coderpunks@toad.com, ietf-open-pgp@imc.org Subject: Re: extensibility & code bloat (Re: PGP cipher tags) In-Reply-To: Message-Id: <97Aug11.095448edt.32260@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Sat, 9 Aug 1997 brianh@risky.bit3.com wrote: > Have people considered seperating the mode from cipher used? Each cipher > would have a small number of functions and constants to define > (functions: expand_key and encrypt_block (which would also decrypt > block), and constants: key_length, expanded_key_length, and > block_length). The next layer would be multi-encryption (for instance, > 3-EDE). The layer above that would be mode (CBC, code book, etc). The > encoding would then be something like: > CBC-3EDE-DES > With the three parts each going to the three layers. > > This would keep code bloat down (among other things, like making > experimentation easier). There would be a slight cost in performance (a > couple of extra function calls, and the dropping of some possible > optimizations- like dropping the initial/final permutations between > rounds of 3DES). > > Thoughts? PGP 5.0 has copied the CFB with IV in the first 8 encrypted bytes with two check bytes from IDEA in 2.6.3 to DES and CAST. It seems to be "baked in". So before we go ahead and propose layering, it might be nice to work out these little details. If CFB is going to be a quirky CFB, will "plain" CFB be another mode? And CBC now exists for 3DES, CAST, and IDEA in other implementations. --- reply to tzeruch - at - ceddec - dot - com --- From owner-ietf-open-pgp Mon Aug 11 06:56:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA27823 for ietf-open-pgp-bks; Mon, 11 Aug 1997 06:56:30 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA27819 for ; Mon, 11 Aug 1997 06:56:26 -0700 (PDT) Received: by brickwall.ceddec.com id <32261>; Mon, 11 Aug 1997 10:01:14 -0400 Date: Mon, 11 Aug 1997 10:01:39 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: Jon Callas cc: Adam Shostack , Jonathan Wienke , jude@pgp.com, coderpunks@toad.com, ietf-open-pgp@imc.org Subject: Re: PGP Message Exchange Formats Internet Draft In-Reply-To: Message-Id: <97Aug11.100114edt.32261@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 8 Aug 1997, Jon Callas wrote: > There's already a constant for RIPE-MD/160. It may have gotten slipped from > that draft. There will be another draft once we're back from Europe. > > Jon Yes, and if anyone bothered to buy the source, they would find out the number is 3. They also might notice that the DSAVerify routine has a line of the form if ( hash_alg != SHA1_hash ) return (bad_alg) So anyone actually using RIPE-MD/160 for signatures will have them shown as bad although they are mathematically correct (also applies to MD5). Speaking of which, since DSA has only 160 bytes, and does not use the ASN1 prefix string that the RSA signatures use, are these going to be dropped? If/when you allow El Gamal signatures, will they be the lower 20 bytes with that PKCS padding and will they use the ASN1 strings, and what are they for RIPE-MD-160 and SHA1 - I think they are blank in the source. --- reply to tzeruch - at - ceddec - dot - com --- From owner-ietf-open-pgp Mon Aug 11 07:23:32 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA28084 for ietf-open-pgp-bks; Mon, 11 Aug 1997 07:23:32 -0700 (PDT) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA28077 for ; Mon, 11 Aug 1997 07:23:24 -0700 (PDT) Received: from LiverStudyUnit (ghost.dialin.utoronto.ca [142.150.128.102]) by psyche.the-wire.com (8.8.6/8.6.12) with ESMTP id KAA05163; Mon, 11 Aug 1997 10:28:02 -0400 (EDT) Message-ID: <33EEDB20.66DEC874@geocities.com> Date: Mon, 11 Aug 1997 10:28:00 +0100 From: Robert Guerra X-Mailer: Mozilla 4.01 [en] (Win95; U) MIME-Version: 1.0 To: "ietf-open-pgp@imc.org" , RProcess Subject: [Fwd: [PGP-USERS] PGP 5.0i is now available ... !] X-Priority: 3 (Normal) Content-Type: multipart/mixed; boundary="------------7FBEC43152A0910EED1D2F1D" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------7FBEC43152A0910EED1D2F1D Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In case this bit of important news yet hasn't made it this way.... --------------7FBEC43152A0910EED1D2F1D Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from mail.torfree.net (root@danforth.torfree.net [199.71.188.17]) by psyche.the-wire.com (8.8.6/8.6.12) with SMTP id JAA01893 for ; Mon, 11 Aug 1997 09:24:19 -0400 (EDT) Received: from joshua.rivertown.net ([204.141.41.5]) by mail.torfree.net (/\==/\ Smail3.1.28.1 #28.8; 15-jan-97) via sendmail with smtp id (sender pgp-users-return-1002-az096=freenet.toronto.on.ca@joshua.rivertown.net) for ; Mon, 11 Aug 97 09:23 EDT Received: (qmail 11028 invoked by alias); 11 Aug 1997 13:20:04 -0000 Mailing-List: contact pgp-users-help@joshua.rivertown.net; run by ezmlm Reply-To: pgp-users@joshua.rivertown.net Delivered-To: mailing list pgp-users@joshua.rivertown.net Received: (qmail 11012 invoked from network); 11 Aug 1997 13:19:55 -0000 Received: from mail.uni-muenster.de (128.176.6.47) by joshua.rivertown.net with SMTP; 11 Aug 1997 13:19:55 -0000 Received: from salma.uni-muenster.de (RAS0004.UNI-MUENSTER.DE [128.176.21.68]) by mail.uni-muenster.de (8.7.5/8.7.5) with SMTP id PAA30268 for ; Mon, 11 Aug 1997 15:19:11 +0200 Message-Id: <3.0.3.32.19970811151741.008003a0@pop.uni-muenster.de> X-Sender: friedrf@pop.uni-muenster.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 11 Aug 1997 15:17:41 +0200 To: pgp-users@joshua.rivertown.net From: "F. A. Friedrichs" Subject: [PGP-USERS] PGP 5.0i is now available ... ! Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hello! The international version of PGP 5.0i is now available at http://www.pgpi.co= m ... >>>> [...] PGP 5.0i released! The platform independent volumes of the PGP 5.0 source code books have now= =20 been scanned in and proof-read. This includes the whole encryption library with= =20 the new algorithms, key formats and keyserver support. A Unix command line version o= f PGP 5.0i is available for download now. The Windows and Macintosh versions will= =20 take a few more weeks to finalize, because the binary files (which are radix64=20 encoded) have shown to be very difficult to proof-read. You can read more about the=20 scanning project here. [...] <<<< Greetings, Frank ... -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBM+8C5UGpOkbLYr2hAQH95gf/V9rAselO4qip8+swkM+0P1jOvpQ3kCsy UJlQ3vd8D3bdbV6d6OThI9ppN3oJ0+t0HrSwsoqPmQhak61v4BuVOhvfMKlHS8Aj 5gl2kHU8SLr6aXNYnza8yqaoxn7bG1VfPmHBhgxPCs9xmAI9AMgH/BdbhmrRRxqZ h3N3hKdxUJmk14QxR+RByY7xKGv+TT01LrNjX+mfFebhRhcOQcwVBZRt4s+Mbxo/ SVr047tEEaIFdlPrQGZ+qSFiVK/fFG3btPCepq4m6wuKv8X+wS8EQW5OgnTjF7qj TKnD866czTFFsT7dyccKnCHhq2uExL3xlryirZzZ4g4EbHMKKX0q3A=3D=3D =3DsugY -----END PGP SIGNATURE----- __________________________________________________________________ Frank A. Friedrichs http://faf.home.pages.de/ 2048bits-RSA-PGPKeyID:0xCB62BDA1 4096bits-RSA-PGPKeyID:0x65DDC189 2048: mailto:pgp-public-keys@keys.pgp.net?Subject=3DGET%200xCB62BDA1 4096: mailto:pgp-public-keys@keys.pgp.net?Subject=3DGET%200x65DDC189 =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF --------------7FBEC43152A0910EED1D2F1D-- From owner-ietf-open-pgp Mon Aug 11 07:46:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA28336 for ietf-open-pgp-bks; Mon, 11 Aug 1997 07:46:48 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA28330 for ; Mon, 11 Aug 1997 07:46:43 -0700 (PDT) Received: by brickwall.ceddec.com id <32259>; Mon, 11 Aug 1997 10:51:34 -0400 Date: Mon, 11 Aug 1997 10:52:04 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: coderpunks@toad.com cc: ietf-open-pgp@imc.org Subject: Re: PGP Message Exchange Formats Internet Draft In-Reply-To: <97Aug11.100114edt.32261@brickwall.ceddec.com> Message-Id: <97Aug11.105134edt.32259@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Mon, 11 Aug 1997 root@mars.ceddec.com wrote: > if ( hash_alg != SHA1_hash ) > return (bad_alg) Now that I have downloaded the source: pgpDSAKey.c, around line 175, in dsaVerify: if (h->type != PGP_HASH_SHA) return 0; /* No match for sure! */ --- reply to tzeruch - at - ceddec - dot - com --- From owner-ietf-open-pgp Mon Aug 11 07:52:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA28436 for ietf-open-pgp-bks; Mon, 11 Aug 1997 07:52:18 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA28432 for ; Mon, 11 Aug 1997 07:52:14 -0700 (PDT) Received: by brickwall.ceddec.com id <32258>; Mon, 11 Aug 1997 10:56:56 -0400 Date: Mon, 11 Aug 1997 10:57:29 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: coderpunks@toad.com cc: ietf-open-pgp@imc.org Subject: Re: PGP Message Exchange Formats Internet Draft In-Reply-To: <97Aug11.100114edt.32261@brickwall.ceddec.com> Message-Id: <97Aug11.105656edt.32258@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Mon, 11 Aug 1997 root@mars.ceddec.com wrote: > Speaking of which, since DSA has only 160 bytes, and does not use the ASN1 OOPS----------------------------------------bits------------------------DER? > prefix string that the RSA signatures use, are these going to be dropped? > If/when you allow El Gamal signatures, will they be the lower 20 bytes > with that PKCS padding and will they use the ASN1 strings, and what are > they for RIPE-MD-160 and SHA1 - I think they are blank in the source. Ah, those do use the PKCS padding and the DER prefixes. --- reply to tzeruch - at - ceddec - dot - com --- From owner-ietf-open-pgp Mon Aug 11 14:46:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA04494 for ietf-open-pgp-bks; Mon, 11 Aug 1997 14:46:49 -0700 (PDT) Received: from cygnus.com (cygnus.com [205.180.230.20]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA04490 for ; Mon, 11 Aug 1997 14:46:45 -0700 (PDT) Received: from cygnus.com (ip-pdx36-22.teleport.com [206.163.127.149]) by cygnus.com (8.8.5/8.8.5) with ESMTP id OAA00345; Mon, 11 Aug 1997 14:51:19 -0700 (PDT) Message-Id: <199708112151.OAA00345@cygnus.com> From: Felix Lee Subject: Re: PGP Message Exchange Formats Internet Draft To: Hagen Wollert Cc: ietf-open-pgp@imc.org, coderpunks@toad.com In-reply-to: Your message of Mon, 11 Aug 1997 15:52:41 +0200. <1.5.4.16.19970811135241.32efdc48@pop.rz.tu-clausthal.de> Date: Mon, 11 Aug 1997 14:51:38 -0700 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > I'm afraid for the moment we are at a point here it is to decide whether to > imply anything into one comprehensive format (like Tiff) or have many > formats parallel formats like a set of (Tiff, Gif, JPEG, TGA, BMP, PCX, > etc.) with a whole lot of compatbility problems in the future. just want to point out: comprehensive format is not sufficient to solve compatibility problems. Tiff is a case in point. -- From owner-ietf-open-pgp Tue Aug 12 07:40:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA13818 for ietf-open-pgp-bks; Tue, 12 Aug 1997 07:40:16 -0700 (PDT) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by mail.proper.com (8.8.5/8.7.3) with SMTP id HAA13812 for ; Tue, 12 Aug 1997 07:40:13 -0700 (PDT) Message-Id: <199708121440.HAA13812@mail.proper.com> Received: (qmail 27101 invoked from network); 12 Aug 1997 14:44:53 -0000 Received: from laf-0000-25.iquest.net (HELO ?204.95.254.185?) (204.95.254.185) by iquest3.iquest.net with SMTP; 12 Aug 1997 14:44:53 -0000 X-Mailer: EnRoute for Newton, Version 1.4.2a3 Mime-Version: 1.0 (Generated by EnRoute for Newton) Date: Tue, 12 Aug 1997 09:41 -0500 (EST) Subject: Re: algorithm ID encodings & terminol. From: Jason Dufair To: allas Jon , "nospam-seesignature@ceddec.com" Cc: Adam Back , "coderpunks@toad.com" , "ietf-open-pgp@imc.org" Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk ------------------ >You obviously were never an embedded systems programmer :). > >After you expand everything to need a 256K buffer, you can have the fun of >coding PGP5 for the USR Palm Pilot :). ------------------ I am indeed porting PGP 5 to the Newton MessagePad. While it is less restrictive than the Pilot, I would not classify it as "fun". :-) ----- Jason Dufair funne@iquest.net http://www.iquest.net/~funne see http://www.iquest.net/~funne/jdufair.asc for PGP 2.x public key -Sent via the Newton MP2000- From owner-ietf-open-pgp Tue Aug 12 11:35:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA16095 for ietf-open-pgp-bks; Tue, 12 Aug 1997 11:35:18 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA16091 for ; Tue, 12 Aug 1997 11:35:14 -0700 (PDT) Received: by brickwall.ceddec.com id <32258>; Tue, 12 Aug 1997 14:40:04 -0400 Date: Tue, 12 Aug 1997 14:41:45 -0400 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars.ceddec.com To: coderpunks@toad.com cc: ietf-open-pgp@imc.org Subject: Re: extensibility & code bloat (Re: PGP cipher tags) In-Reply-To: <97Aug11.095448edt.32258@brickwall.ceddec.com> Message-Id: <97Aug12.144004edt.32258@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk In pgp 5.0: There are 2 Public Key Algorithms, 3 Conventional Algorithms, 3 Hashes, and 3 signature algorithms (with El Gamal enabled - it does work). 54 ways to send your encrypted signed message. Playing with a full deck plus two jokers? pgpv handles all these variants properly (the just scanned in version), but how do I get pgpe (for any platform) to generate all of them? --- reply to tzeruch - at - ceddec - dot - com --- From owner-ietf-open-pgp Wed Aug 13 00:47:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA21599 for ietf-open-pgp-bks; Wed, 13 Aug 1997 00:47:24 -0700 (PDT) Received: from grinch.whoville.leftbank.com (grinch.leftbank.com [139.167.128.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id AAA21593 for ; Wed, 13 Aug 1997 00:47:19 -0700 (PDT) Received: from zax.whoville.leftbank.com by grinch.whoville.leftbank.com via smtpd (for mail.proper.com [206.184.129.129]) with SMTP; 13 Aug 1997 07:52:05 UT Received: from max.whoville.leftbank.com (max.whoville.leftbank.com [139.167.32.1]) by zax.leftbank.com (8.7.5/8.7.3/LeftBank-1.1/http://www.leftbank.com/) with SMTP id DAA13722 for ; Wed, 13 Aug 1997 03:53:43 -0400 (EDT) Received: from lbo.leftbank.com ([192.31.227.130]) by max.whoville.leftbank.com via smtpd (for zax.whoville.leftbank.com [139.167.32.33]) with SMTP; 13 Aug 1997 07:52:03 UT Received: from laptop-static-rodney.ietf.de (Laptop-static-rodney.ietf.de [195.27.194.28]) by lbo.leftbank.com (8.8.5/8.7.3/http://www.LeftBank.Com) with SMTP id DAA02095 for ; Wed, 13 Aug 1997 03:52:02 -0400 (EDT) Message-Id: <3.0.1.32.19970813095148.0080cc80@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 13 Aug 1997 09:51:48 -0400 To: ietf-open-pgp@imc.org From: Rodney Thayer Subject: BOF at IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In a fit of uncontrolled volunteerism I managed to offer to write up the minutes to the BOF (meeting) at the IETF. I've got that partially complete and will be posting it shortly. I would appreciate any feedback if I failed to record something or made any mis-statements. -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBM/G79IwpVk/gvJfqEQKONACg3hufvK3cyURGsq5UpzcwLyj6FTIAoIUX lSFczwgr6gwjud+olYDPNXkj =bTME -----END PGP SIGNATURE----- -- Rodney Thayer Sable Technology +1 617 332 7292 -- From owner-ietf-open-pgp Wed Aug 13 10:48:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA29836 for ietf-open-pgp-bks; Wed, 13 Aug 1997 10:48:41 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA29831 for ; Wed, 13 Aug 1997 10:48:37 -0700 (PDT) Received: by brickwall.ceddec.com id <32263>; Wed, 13 Aug 1997 13:52:41 -0400 Date: Wed, 13 Aug 1997 13:55:09 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: ietf-open-pgp@imc.org cc: coderpunks@toad.com Subject: Re: extensibility & code bloat (Re: PGP cipher tags) In-Reply-To: <970811083807.20204005@hobbes.orl.lmco.com> Message-Id: <97Aug13.135241edt.32263@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Mon, 11 Aug 1997, A. Padgett Peterson P.E. Information Security wrote: > Have come to the conclusion that and ASCIIZ string is the proper answer > with 00h indicating either none or the end of the matter. This way > it can be > 1) Intelligible > 2) If the vendor wants to use a single byte, they can (with reguistration) And in 8.3 of the spec, part of the signature is now: Preferred symmetric algorithms (array of 1 byte) (Hashed) Symmetric algorithm numbers that indicate which algorithms the key holder prefers to use. This is an ordered list of bytes with the most preferred listed first. It should be assumed that only algorithms listed are supported by the ------------------------------------------------- recipient's software. Algorithm numbers are provided below. If this subpacket is not included, IDEA is assumed. This is found on a self-signature. This could get really fun. If I don't include IDEA and/or CAST explicitly, but only have "\377Blowfish\0", no one could send me a message even if the software did support the other algorithms. And how do I specify I prefer RIPEMD160 hashes in El Gamal signatures? --- reply to tzeruch - at - ceddec - dot - com --- From owner-ietf-open-pgp Thu Aug 21 04:59:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id EAA17371 for ietf-open-pgp-bks; Thu, 21 Aug 1997 04:59:12 -0700 (PDT) Received: from boeing.rutgers.edu (boeing.rutgers.edu [165.230.8.73]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id EAA17367 for ; Thu, 21 Aug 1997 04:59:08 -0700 (PDT) Received: (from mione@localhost) by boeing.rutgers.edu (8.8.5/8.6.12) id IAA29975; Thu, 21 Aug 1997 08:04:25 -0400 (EDT) From: "Tony Mione" Message-Id: <970821080425.ZM29973@boeing.rutgers.edu> Date: Thu, 21 Aug 1997 08:04:24 -0400 X-Mailer: Z-Mail (4.0.1 13Jan97) To: ietf-open-pgp@imc.org Subject: Comments on draft-ietf-pgp-formats00.txt Cc: mione@virtuoso.Rutgers.EDU MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I have a couple of questions and comments about the draft: 1) Was there a technical reason for the new packet length format. Limiting packets larger than 8383 bytes to powers of two seems a bit restrictive. Also, if that scheme is left in place, you should describe how padding is done and how to find the end of useful data. 2) It is not clear whether this document is supersceding or supplementing RFC1991. The introduction suggests it is supplementing. In that case, I would not repeat anything from RFC1991 so as not to 'blimp-out' this document. One place you do this is in describing the CTB and packet length formats. If this is a supplement, then simply refer the reader to RFC1991 since this format is not generated by newer PGPs. Note that this does not apply to elements that are still valid for the new PGP formats. For instance, you must still define all of the packet types that are still in use with the new PGP. 3) I also agree with earlier comments on the list that all currently supported packet types should be fully documented, not just 'some of the more interesting packet types'. 4) It would be really helpful to use ascii-character box diagrams to illustrate the CTB, packet length, and the assorted packet layouts (ala older IP/TCP RFCs). They look kind of old and crufty but can clear up a great deal of confusion when done correctly. -- Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650 mione@nbcs-ns.rutgers.edu W3: http://www-ns.rutgers.edu/~mione/ PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F Editorial Advisor for Digital Systems Report ***** Important: John 17:3 ***** From owner-ietf-open-pgp Thu Aug 21 15:14:08 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA24826 for ietf-open-pgp-bks; Thu, 21 Aug 1997 15:14:08 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA24814 for ; Thu, 21 Aug 1997 15:14:04 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id PAA02674 for ; Thu, 21 Aug 1997 15:19:22 -0700 (PDT) Message-Id: <3.0.2.32.19970821152347.00b74810@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 21 Aug 1997 15:23:47 -0700 To: ietf-open-pgp@imc.org From: Charles Breed Subject: PROPOSED OPEN-PGP Charter Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Please review the following proposed charter, reply "YES" if you agree or suggest modifications. thanks, CB ----------------------------------------------------- PROPOSED OPEN-PGP Charter Description of the Working Group: The OPEN-PGP Working Group is chartered with defining a standard method to send and receive encrypted and / or digitally signed data objects that interoperate. The group will place particular emphasis on strong cryptography based on open and freely available algorithms. The specification will define the message formats, certificate structure, required cryptographic algorithms and key lengths, and other relevant operational concerns. The OPEN-PGP Specification will have provisions for; 1. interoperability using cryptographic algorithms (asymmetric/symmetric including key lengths) that are consider strong, open and unencumbered, and other algorithms MAY be used 2. limited backwards compatibility with the existing pgp message 3. Government and legislative policies from any country SHOULD not impact the specification 4. certificate structure and underlying trust models, as used in a public key infrastructure 5. certificate and message format 6. basic time stamping service 7. MIME content types will reference RFC 2015 Goals and Milestones: October 1997: Submit first internet draft of OPEN-PGP certificate and message specification November 1997: Submit first internet draft of OPEN-PGP PKI, Trust Model and Time Stamping March 1998: Submit OPEN-PGP certificate and message specification for final call April 1998: Submit OPEN-PGP PKI, Trust Model, Time Stamping for final call May 1998: Submit OPEN-PGP certificate and message specification for Proposed Standard July 1998: WG last call on both drafts for Proposed Standard, (including RFC 2015) Chairpersons: John W. Noerenberg, II Charles J. Breed co-chair From owner-ietf-open-pgp Fri Aug 22 09:48:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA09701 for ietf-open-pgp-bks; Fri, 22 Aug 1997 09:48:35 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA09697 for ; Fri, 22 Aug 1997 09:48:32 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id JAA13691; Fri, 22 Aug 1997 09:53:51 -0700 (PDT) Message-Id: <3.0.2.32.19970822095815.00b60da0@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 22 Aug 1997 09:58:15 -0700 To: Jason Dufair From: Charles Breed Subject: RE: PROPOSED OPEN-PGP Charter Cc: ietf-open-pgp@imc.org In-Reply-To: <199708221314.GAA11922@fusebox.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jason, Some thought went into the phrase, "limited backwards compatibility", If you implement "open-pgp" with Diffie-Hellman Public Key Algorithm and / or use a X.509v3 cert, you'll have problems getting FULL compatibility with 2.6.x. I agree that we do not want to abandon or inhibit any of the 4 million existing users, and the spec will require the new and old versions to communicate to some usefull degree. CB At 08:09 AM 8/22/97 -0500, Jason Dufair wrote: > >Charles - > >YES. I agree. I am concerned with the "limited backwards compatibility." I >believe all 2.6.x message structures should be preserved. What, exactly, is >meant by "limited backwards compatibility?" > >Thanks for your time. > > >>2. limited backwards compatibility with the existing pgp message >Jason Dufair >funne@iquest.net >http://www.iquest.net/~funne >see http://www.iquest.net/~funne/jdufair.asc for PGP 2.x public key >-Sent via the Newton MP2000- > From owner-ietf-open-pgp Fri Aug 22 10:04:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA09850 for ietf-open-pgp-bks; Fri, 22 Aug 1997 10:04:34 -0700 (PDT) Received: from hobbes.orl.lmco.com (hobbes.orl.lmco.com [141.240.192.100]) by mail.proper.com (8.8.5/8.7.3) with SMTP id KAA09846 for ; Fri, 22 Aug 1997 10:04:31 -0700 (PDT) Date: Fri, 22 Aug 1997 13:08:48 -0400 (EDT) From: "A. Padgett Peterson P.E. Information Security" To: cbreed@pgp.com CC: ietf-open-pgp@imc.org Message-Id: <970822130848.20209252@hobbes.orl.lmco.com> Subject: RE: PROPOSED OPEN-PGP Charter Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Looks pretty good but would like some clarification: The OPEN-PGP Specification will have provisions for; 1. interoperability using cryptographic algorithms (asymmetric/symmetric including key lengths) that are consider strong, open and unencumbered, and other algorithms MAY be used This is not very good English - the word "may" removes any meaning/force. 2. limited backwards compatibility with the existing pgp message What is meant by "limited" - read/verify signature only ? "Standard" should not be concerned with licening unless the intent is only to allow Public Domain algoritms in which case shouldn't that be in (1) ? 3. Government and legislative policies from any country SHOULD not impact the specification Word "SHOULD" makes it a null statement - has same effect as "MAY" Rest is pretty much no-braners. Personal feelings are that the top level standard needs to be as open as possible while allowing for subsets. That is that all possible configurations need to be allowed while subsets are created for special circumstances such as France. "What the large print giveth, the small print taketh away..." Warmly, Padgett From owner-ietf-open-pgp Fri Aug 22 10:25:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA10048 for ietf-open-pgp-bks; Fri, 22 Aug 1997 10:25:15 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA10043 for ; Fri, 22 Aug 1997 10:25:12 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id KAA14200; Fri, 22 Aug 1997 10:29:15 -0700 (PDT) Message-Id: <3.0.2.32.19970822103340.00b67290@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 22 Aug 1997 10:33:40 -0700 To: "A. Padgett Peterson P.E. Information Security" From: Charles Breed Subject: RE: PROPOSED OPEN-PGP Charter Cc: ietf-open-pgp@imc.org In-Reply-To: <970822130848.20209252@hobbes.orl.lmco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hello Padgett, 1) The word phrase "MAY use other algorithms", refers to those who want to include ANY cryptographic algorithm. If you want to implement "OPEN-PGP" with RSA, or some ECC asymmetric algorithm that has intellectual property rights issues, you SHOULD be able to do so. We simply would not make it a REQUIREMENT. 2) I just answered a similar question wrt "Limited" to the list. 3) "Government and legislative policies SHOULD not..." Take the inverse of this statement; IF the US Gov. says you MUST use a minimum of 128 key lengths...then our charter would get confusing. I think the intent is well understood, forcing a 40 key as a MUST is not a 'technically appropriate thing' Your last statement is right on the money ! Peace >That is that all possible configurations need to be allowed >while subsets are created for special circumstances such as France. Cheers, CB At 01:08 PM 8/22/97 -0400, you wrote: >Looks pretty good but would like some clarification: > >The OPEN-PGP Specification will have provisions for; >1. interoperability using cryptographic algorithms (asymmetric/symmetric > including key lengths) that are consider strong, open and unencumbered, > and other algorithms MAY be used > >This is not very good English - the word "may" removes any meaning/force. > >2. limited backwards compatibility with the existing pgp message > >What is meant by "limited" - read/verify signature only ? "Standard" should >not be concerned with licening unless the intent is only to allow Public >Domain algoritms in which case shouldn't that be in (1) ? > >3. Government and legislative policies from any country SHOULD not impact the specification > >Word "SHOULD" makes it a null statement - has same effect as "MAY" > >Rest is pretty much no-braners. > >Personal feelings are that the top level standard needs to be as open as >possible while allowing for subsets. That is that all possible configurations >need to be allowed while subsets are created for special circumstances >such as France. > >"What the large print giveth, the small print taketh away..." > > Warmly, > Padgett > > From owner-ietf-open-pgp Fri Aug 22 15:06:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA12252 for ietf-open-pgp-bks; Fri, 22 Aug 1997 15:06:06 -0700 (PDT) Received: from merit.edu (merit.edu [198.108.1.42]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA12244 for ; Fri, 22 Aug 1997 15:06:00 -0700 (PDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm036-00.dialip.mich.net [141.211.7.42]) by merit.edu (8.8.7/8.8.5) with SMTP id SAA07495 for ; Fri, 22 Aug 1997 18:11:21 -0400 (EDT) Date: Fri, 22 Aug 97 21:41:23 GMT From: "William Allen Simpson" Message-ID: <6455.wsimpson@greendragon.com> To: ietf-open-pgp@imc.org Subject: Re: PROPOSED OPEN-PGP Charter Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > From: Charles Breed > The OPEN-PGP Specification will have provisions for; > 1. interoperability using cryptographic algorithms (asymmetric/symmetric including key lengths) that are consider strong, open and unencumbered, and other algorithms MAY be used This should be more than one sentence. How about: 1. mandatory support for strong, open and unencumbered cryptographic algorithms. Other algorithms may be optionally specified, but will not be required for conformance. > 2. limited backwards compatibility with the existing pgp message I am concerned. How about: 2. strong backwards compatibility with the pgp 5.0, with limited support for earlier pgp version installed base. > 3. Government and legislative policies from any country SHOULD not impact the specification Better: 3. Government and legislative policies MUST NOT impact the specification. > 4. certificate structure and underlying trust models, as used in a public key infrastructure Which public key infrastructure? I am planning on writing up SPKI-like message formats that use the PGP CTB space -- this weekend. > 5. certificate and message format > 6. basic time stamping service > 7. MIME content types will reference RFC 2015 > > Goals and Milestones: > A rather aggressive schedule. Probably will slip. > Chairpersons: > > John W. Noerenberg, II > Charles J. Breed co-chair > Good luck, and thanks! WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ietf-open-pgp Fri Aug 22 15:06:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA12251 for ietf-open-pgp-bks; Fri, 22 Aug 1997 15:06:04 -0700 (PDT) Received: from merit.edu (merit.edu [198.108.1.42]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA12241 for ; Fri, 22 Aug 1997 15:05:59 -0700 (PDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm036-00.dialip.mich.net [141.211.7.42]) by merit.edu (8.8.7/8.8.5) with SMTP id SAA07492 for ; Fri, 22 Aug 1997 18:11:20 -0400 (EDT) Date: Fri, 22 Aug 97 21:35:24 GMT From: "William Allen Simpson" Message-ID: <6454.wsimpson@greendragon.com> To: ietf-open-pgp@imc.org Subject: Re: RE: PROPOSED OPEN-PGP Charter Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Charles, I am having problems reading your messages. For some reason, they don't fold in 80 columns, and in fact sometimes run beyond the 1000 characters per line (including CRLF) allowed by RFC-821. Could you please resend the charter and your replies? > From: Charles Breed > X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ietf-open-pgp Fri Aug 22 15:31:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA12429 for ietf-open-pgp-bks; Fri, 22 Aug 1997 15:31:59 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA12424 for ; Fri, 22 Aug 1997 15:31:56 -0700 (PDT) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id PAA19017; Fri, 22 Aug 1997 15:37:17 -0700 (PDT) Message-Id: <3.0.2.32.19970822153139.009ad6d0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 22 Aug 1997 15:31:39 -0700 To: "Tony Mione" , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Comments on draft-ietf-pgp-formats00.txt In-Reply-To: <970821080425.ZM29973@boeing.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 08:04 AM 8/21/97 -0400, Tony Mione wrote: I have a couple of questions and comments about the draft: 1) Was there a technical reason for the new packet length format. Limiting packets larger than 8383 bytes to powers of two seems a bit restrictive. Also, if that scheme is left in place, you should describe how padding is done and how to find the end of useful data. I described this incompletely. I'll put the full description in the next release. 2) It is not clear whether this document is supersceding or supplementing RFC1991. The introduction suggests it is supplementing. This document is superceding RFC1991. I plan on rewriting all parts of RFC1991 that need updating, correcting, etc. 3) I also agree with earlier comments on the list that all currently supported packet types should be fully documented, not just 'some of the more interesting packet types'. I agree completely. As charming as this phrase is, it is one of the phrases from RFC1991 that need to be drabbed-down. 4) It would be really helpful to use ascii-character box diagrams to illustrate the CTB, packet length, and the assorted packet layouts (ala older IP/TCP RFCs). They look kind of old and crufty but can clear up a great deal of confusion when done correctly. Thanks for the suggestion, I'll look at it. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 From owner-ietf-open-pgp Fri Aug 22 21:45:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA14426 for ietf-open-pgp-bks; Fri, 22 Aug 1997 21:45:58 -0700 (PDT) Received: from lancelot.st.nepean.uws.edu.au (lancelot.st.nepean.uws.edu.au [137.154.148.30]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id VAA14422 for ; Fri, 22 Aug 1997 21:45:49 -0700 (PDT) Received: from oberon.st.nepean.uws.edu.au (oberon [137.154.148.13]) by lancelot.st.nepean.uws.edu.au (8.8.5/8.8.5) with ESMTP id OAA18298; Sat, 23 Aug 1997 14:50:27 +1000 Received: from shirley (dformosa@nero-asy-24.nepean.uws.edu.au [137.154.196.214]) by oberon.st.nepean.uws.edu.au (8.8.5/8.8.5) with SMTP id OAA20190; Sat, 23 Aug 1997 14:50:22 +1000 (EST) Date: Sat, 23 Aug 1997 10:40:11 +1000 (EST) From: ? the Platypus {aka David Formosa} X-Sender: dformosa@shirley Reply-To: platypus@acmeonline.net To: "A. Padgett Peterson P.E. Information Security" cc: cbreed@pgp.com, ietf-open-pgp@imc.org Subject: RE: PROPOSED OPEN-PGP Charter In-Reply-To: <970822130848.20209252@hobbes.orl.lmco.com> Message-ID: x-url: http://www.st.nepean.uws.edu.au/~dformosa/Spelling.html MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Fri, 22 Aug 1997, A. Padgett Peterson P.E. Information Security wrote: > The OPEN-PGP Specification will have provisions for; > 1. interoperability using cryptographic algorithms (asymmetric/symmetric > including key lengths) that are consider strong, open and unencumbered, > and other algorithms MAY be used > > This is not very good English - the word "may" removes any meaning/force. I read the MAY as a RFC style requirement. And as such has a (slightly) diffrent meaning to the english one. > 3. Government and legislative policies from any country SHOULD not impact > the specification > > Word "SHOULD" makes it a null statement - has same effect as "MAY" No the meaning is diffrencent. The SHOULD suggests that it is possable but only after we have thought about all the concequencers of this action. - -- Please excuse my spelling as I suffer from agraphia see the url in my header. Never trust a country with more peaple then sheep. ex-net.scum and proud You Say To People "Throw Off Your Chains" And They Make New Chains For Themselves? --Terry Pratchett -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBM/4xc6QK0ynCmdStAQF9ZAP/T4P0Ttdo3XrqBa5C6nfwuwYXNpL9QzDI 9UoRy4ehqI1vtFLL98Z8G3wtriQtCRXvZ/5MFU7i6iLEhqv1xQ7Mc6Cn2rIP1KxA 3LEd/cHv0fSSx+DU0ctEEjtEipUhYNlTABgtFn6AC/sKs3LKphYnsjQWfEIFTOMo kEQzMcPWAcw= =M6KG -----END PGP SIGNATURE----- From owner-ietf-open-pgp Sat Aug 23 10:30:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA19402 for ietf-open-pgp-bks; Sat, 23 Aug 1997 10:30:05 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA19395 for ; Sat, 23 Aug 1997 10:30:00 -0700 (PDT) Received: by brickwall.ceddec.com id <32258>; Sat, 23 Aug 1997 13:35:10 -0400 Date: Sat, 23 Aug 1997 13:35:17 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com Reply-To: tzeruch@ceddec.com To: ietf-open-pgp@imc.org Subject: PGP specification note and suggestion In-Reply-To: <3.0.2.32.19970821152347.00b74810@mail.pgp.com> Message-Id: <97Aug23.133510edt.32258@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >From 3.2: The length field of an MPI describes the length starting from its most significant non-zero bit. Thus, the MPI [00 02 01] is not formed correctly. It should be [00 01 01]. This is required by most earlier versions of PGP (through 2.7.1) for signatures, but not apparently for encryption or decryption. It is not required by 5.0. Note that many RSA implementations return the value the same length as the modulus, which can include leading zeros. Also note that the above bad example would work with the earlier versions of PGP - it simply requried the leading byte not be zero. So, how strict is the MPI format requirement? (another "should" v.s. "must" debate). --- It would help greatly if there was some minimum specification about when data will *NOT* be split into chunks with the new CTB length scheme. e.g. 0xca 0x03 'P' 'G' 'P' is easy to handle, but it would seem that 0xca 0xe0 'P' 0xe0 'G' 0xe0 'P' 0x00 is equally valid (I made this up, so may have erred in the details). I don't want to create another state machine and I/O abstraction layer when I don't have to, and PGP 5.0 doesn't arbitrarily do things like the above. What I would like is that for things like any CTB valid within a keyring, and short (<8381 or whatever) comment type packets, that there will only be *ONE* length entry of one or two bytes as appropriate. If this sounds like it makes sense, I can come up with a comprehensive list, but generally I would only permit it for things that are inherently variable in length (like file data contents). --- Should the new length format be used for compressed blocks? If the compression algorithm will know (or can determine) the length, it is much simpler than having to have one state machine to feed the (de)compressor, and another to dechunk the data stream. In fact, it is cleaner to create a dechunk | decompress pipe, though less efficient, than the merged code - some of the ugliest stuff I have written. I haven't tried generating things with these tiny length-continue segments to see if PGP can handle them. But for smaller machines (e.g. palmtops and PDAs) it would be better not to have to worry about this. From owner-ietf-open-pgp Sat Aug 23 13:24:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA20402 for ietf-open-pgp-bks; Sat, 23 Aug 1997 13:24:29 -0700 (PDT) Received: from merit.edu (merit.edu [198.108.1.42]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA20398 for ; Sat, 23 Aug 1997 13:24:25 -0700 (PDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-24.dialip.mich.net [141.211.7.160]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA16349 for ; Sat, 23 Aug 1997 16:29:48 -0400 (EDT) Date: Sat, 23 Aug 97 14:09:23 GMT From: "William Allen Simpson" Message-ID: <6457.wsimpson@greendragon.com> To: ietf-open-pgp@imc.org Subject: content tag Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I had hoped that someone else would step up to my suggestion that the content tags (nee cipher type) would be carefully listed. Since nobody else has done it, I've started the list. I only have the source to 2.6.2, so here's what I have until 5.0 source is available. Also, I see a very easy method to add SPKI-style SDSI textual conventions to the database format. I've proposed that on the SPKI list, and I've included the simple addition and terminology changes that make this possible. hex length usage element === ====== ===== ======= 00... none /// 09 HT none SPKI VTF 0A... none /// 20 none SPKI VTF 21 none +++ 22 " none SPKI VTF 23 # none SPKI VTF 24... none +++ 28 ( none SPKI S-expression begin 29 ) none SPKI S-expression end 2A... none +++ 30... none SPKI byte-stream format 3B... none +++ 7B { none M SPKI base64-stream begin 7C | none SPKI VTF 7D } none M SPKI base64-stream end 7E none +++ 7F none /// 80 8-bit 255 +++ 81 16-bit +++ 82 32-bit +++ 83 to end +++ 84 8-bit 255 +++ 85 16-bit M Public-Key-Encrypted Symmetric-Key 86 32-bit +++ 87 to end +++ 88 8-bit 255 ??? (check rfc1991 mismatch PGP2.6.2) 89 16-bit I Signature 8A 32-bit +++ 8B to end +++ 8C 8-bit 255 SI Hash??? 8D 16-bit +++??? 8E 32-bit +++??? 8F to end +++??? 90 8-bit 255 +++ 91 16-bit +++ 92 32-bit +++ 93 to end +++ 94 8-bit 255 +++ 95 16-bit X Private-Key 96 32-bit +++ 97 to end +++ 98 8-bit 255 ??? (check rfc1991 mismatch PGP2.6.2) 99 16-bit SI Public-Key 9A 32-bit +++ 9B to end +++ 9C 8-bit 255 +++ 9D 16-bit +++ 9E 32-bit +++ 9F to end +++ A0 8-bit 255 +++ A1 16-bit +++ A2 32-bit +++ A3 to end M Compressed Data A4 8-bit 255 --- A5 16-bit --- A6 32-bit --- A7 to end M Symmetric-Key-Encrypted Data A8 8-bit 255 ? Version? A9 16-bit ---? AA 32-bit ---? AB to end M Obsolete-Literal? AC 8-bit 255 +++ AD 16-bit +++ AE 32-bit +++ AF to end M Fixed-Literal B0 8-bit 255 A Trust??? B1 16-bit +++??? B2 32-bit +++??? B3 to end +++??? B4 8-bit 255 A Name B5 16-bit --- B6 32-bit --- B7 to end --- B8 8-bit 255 +++ B9 16-bit +++ BA 32-bit +++ BB to end +++ (?) BC 8-bit 255 +++ BD 16-bit +++ BE 32-bit +++ BF to end +++ C0 V +++ C1 V Public-Key-Encrypted Symmetric-Key C2 V Signature (etc.) Usage: A Assertion I Issuer M Message only S Subject X DataBase (KeyRing) only +++: For future use. A CTB with this value is skipped, using the specified length. ---: Never generated (extension conflict). A CTB with this value is skipped, using the specified length. ///: MUST NOT be used. A CTB with this value causes a processing abort. SPKI VTF: Visual Textual Format. A CTB with this value causes a processing abort. to end: Indeterminate length runs to end of data. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ietf-open-pgp Sun Aug 24 13:25:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA29829 for ietf-open-pgp-bks; Sun, 24 Aug 1997 13:25:42 -0700 (PDT) Received: from merit.edu (merit.edu [198.108.1.42]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA29825 for ; Sun, 24 Aug 1997 13:25:34 -0700 (PDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-04.dialip.mich.net [141.211.7.15]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA25518 for ; Sun, 24 Aug 1997 16:31:02 -0400 (EDT) Date: Sun, 24 Aug 97 19:33:55 GMT From: "William Allen Simpson" Message-ID: <6462.wsimpson@greendragon.com> To: ietf-open-pgp@imc.org Subject: ASCII box diagrams Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > From: Jon Callas > At 08:04 AM 8/21/97 -0400, Tony Mione wrote: > 4) It would be really helpful to use ascii-character box diagrams to > illustrate the CTB, packet length, and the assorted packet layouts (ala > older > IP/TCP RFCs). They look kind of old and crufty but can clear up a great > deal > of confusion when done correctly. > > Thanks for the suggestion, I'll look at it. > I suggest something like the following: 5.1 Public-Key-Encrypted Symmetric-Key +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Content | Length* | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PK-Identifier ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PK-Algorithm | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Content (CTB) 0x85 Length* 2 bytes. Range 10 to 8191, beginning with Version field. Will PGP 2.6.2 generate a 2 byte length even when a short (256 bit) RSA key is used??? Will a 1 byte length be interpreted correctly by 2.6 and 5.0??? Need testing. Version 1 byte. Indicates format. Valid values are: (2) identical to format (3). (3) current format described. The change in version from (2) to (3) prevents early releases of PGP from parsing output from later releases, but has no other effect. See "Version Fields" for details. Public-Key-Identifier (PKID) 8 bytes. Aids in identifying the public key used to encrypt the symmetric session key. See "Public Keys" for details. PK-Algorithm (PKA) 1 byte. The public-key algorithm used. See "Public Keys" for details. Valid values are: (1) RSA Data variable. A string of octets that is the encrypted symmetric session key. This element is used in a message. One or more of these elements precede a Symmetric-Key-Encrypted Data Element. The recipient of the message finds a PK-Identifier that matches their public key, decrypts the symmetric session key, and then uses the session key to decrypt the Data Element. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ietf-open-pgp Mon Aug 25 08:16:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA08924 for ietf-open-pgp-bks; Mon, 25 Aug 1997 08:16:25 -0700 (PDT) Received: from hail.ncr.disa.mil (hail.ncr.disa.mil [164.117.176.115]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA08920 for ; Mon, 25 Aug 1997 08:16:21 -0700 (PDT) Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id LAA07906; Mon, 25 Aug 1997 11:15:27 -0400 (EDT) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA872533046; Mon, 25 Aug 97 11:07:17 EST Date: Mon, 25 Aug 97 11:07:17 EST From: "David Gaon" Message-Id: <9707258725.AA872533046@ncr.disa.mil> To: cbreed@pgp.com, ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Charles 1. Great - happy to see it coming - comments below 2. >>Charter - The group will place particular emphasis on strong cryptography based on open and freely available algorithms.<< Fully concur >>Charter - 1. interoperability using cryptographic algorithms >>(asymmetric/symmetric including key lengths) that are consider >>strong, open and unencumbered, and Is there any way of ensuring (or at least attempting) interoperability amongst mesage security applications (e.g. PGP and RSA. My understanding is that even if the 2 applications use the same algorithms, they are still not interoperable) Allen Simpson wrote: >>>1. mandatory support for strong, open and unencumbered >>>cryptographic algorithms. Other algorithms may be optionally >>>specified, but will >>not be required for conformance. I disagree - There MUST NOT be any mandatory requirements for algorithms, keys, ... If two correspondents need to correspond securely, they must first establish their respective mail security capabilities (ie find out what they can receive) through the use of other relevant mail capabilities such as Directories. If they h ave compoatible capabilities, they will correspond, if they do not, tough luck. This is no problem for e-commerce because I expect commercial enterprises will implement a multitude of security capabilities to satisfy their cusdtomers. 3. >>Charter - 2. limited backwards compatibility with the existing pgp message ""Limited"" is good - anything more (as Allen Simpson suggested) will encumber (and probably regress) the specification 4. >>Charter - 3. Government and legislative policies from any country >>SHOULD not impact the specification How about: ""3. Gov and legislative policies from any country SHALL NOT be considered nor shall they be caused to impact the specifications"" I think this what you intend! 5. >>Charter - 5. certificate and message format Could we work towards unifying the different secure mail messsage formats floating around and making this the unified format Cheers David Gaon From owner-ietf-open-pgp Mon Aug 25 09:47:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA09914 for ietf-open-pgp-bks; Mon, 25 Aug 1997 09:47:35 -0700 (PDT) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA09909 for ; Mon, 25 Aug 1997 09:47:32 -0700 (PDT) Received: from [165.227.249.112] (buddhi.proper.com [165.227.249.112]) by proper.com (8.8.7/8.7.3) with ESMTP id JAA01817 for ; Mon, 25 Aug 1997 09:48:49 -0700 (PDT) Message-Id: In-Reply-To: <9707258725.AA872533046@ncr.disa.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Aug 1997 09:53:20 -0700 To: ietf-open-pgp@imc.org From: Paul Hoffman / IMC Subject: Re: Sender: owner-ietf-open-pgp@imc.org Precedence: bulk The charter proposal looks pretty good. However, I think a more easy to follow list of the provisions might be: The resulting work will specify: 1. certificate and message formats that have limited backwards compatibility with the existing PGP message format described in RFC 1991 2. a public key infrastructure and trust model 3. basic time stamping capabilities 4. mandatory minimum specifications for encryption and key exchange that are chosen without concern for any government policies and that are consider strong, open, and unencumbered by intellectual property rights 5. a MIME structure similar (if not identical) to RFC 2015 >Chairpersons: > >John W. Noerenberg, II >Charles J. Breed co-chair My experience has been that two chairpeople don't do a better job than one. In this case, since Charles currently works for the company whose employees have written the drafts we'll probably consider, I think that a single chairman, John Noerenberg, would be better than two. (Disclaimer: both people work for members of IMC, and John's on our board of directors.) At 9:07 AM -0700 8/25/97, David Gaon wrote: > I disagree - There MUST NOT be any mandatory requirements for > algorithms, keys, ... > If two correspondents need to correspond securely, they must first > establish their respective mail security capabilities (ie find out > what they can receive) through the use of other relevant mail > capabilities such as Directories. > If they h ave compoatible capabilities, they will correspond, if they > do not, tough luck. This is no problem for e-commerce because I > expect commercial enterprises will implement a multitude of security > capabilities to satisfy their cusdtomers. The IESG rejected the TLS (SSL) Working Group's efforts because they didn't include a mandatory minimum. Although they haven't said that they would do that for all security protocols, it seems likely they will. Thus, I think this group needs to have mandatory minimums if we want to have our work be on standards track. > >>Charter - 5. certificate and message format > > Could we work towards unifying the different secure mail messsage > formats floating around and making this the unified format Well, given that the other popular format (S/MIME) uses a very different underlying format (PKCS #7), "unifying" can't happen at the same time as any backwards compatibility with earlier PGP (or, conversely, with earlier S/MIME). I think it is better to stay focused on the work described above. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-open-pgp Mon Aug 25 09:56:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA10024 for ietf-open-pgp-bks; Mon, 25 Aug 1997 09:56:55 -0700 (PDT) Received: from hail.ncr.disa.mil (hail.ncr.disa.mil [164.117.176.115]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA10020 for ; Mon, 25 Aug 1997 09:56:51 -0700 (PDT) Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id MAA01796; Mon, 25 Aug 1997 12:56:20 -0400 (EDT) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA872539155; Mon, 25 Aug 97 12:55:24 EST Date: Mon, 25 Aug 97 12:55:24 EST From: "David Gaon" Message-Id: <9707258725.AA872539155@ncr.disa.mil> To: cbreed@pgp.com, ietf-open-pgp@imc.org Subject: RE: PROPOSED OPEN-PGP Charter Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Charles 1. Great - happy to see it coming - comments below 2. >>Charter - The group will place particular emphasis on strong cryptography based on open and freely available algorithms.<< Fully concur >>Charter - 1. interoperability using cryptographic algorithms >>(asymmetric/symmetric including key lengths) that are consider >>strong, open and unencumbered, and Is there any way of ensuring (or at least attempting) interoperability amongst mesage security applications (e.g. PGP and RSA. My understanding is that even if the 2 applications use the same algorithms, they are still not interoperable) Allen Simpson wrote: >>>1. mandatory support for strong, open and unencumbered >>>cryptographic algorithms. Other algorithms may be optionally >>>specified, but will >>not be required for conformance. I disagree - There MUST NOT be any mandatory requirements for algorithms, keys, ... If two correspondents need to correspond securely, they must first establish their respective mail security capabilities (ie find out what they can receive) through the use of other relevant mail capabilities such as Directories. If they h ave compoatible capabilities, they will correspond, if they do not, tough luck. This is no problem for e-commerce because I expect commercial enterprises will implement a multitude of security capabilities to satisfy their cusdtomers. 3. >>Charter - 2. limited backwards compatibility with the existing pgp message ""Limited"" is good - anything more (as Allen Simpson suggested) will encumber (and probably regress) the specification 4. >>Charter - 3. Government and legislative policies from any country >>SHOULD not impact the specification How about: ""3. Gov and legislative policies from any country SHALL NOT be considered nor shall they be caused to impact the specifications"" I think this what you intend! 5. >>Charter - 5. certificate and message format Could we work towards unifying the different secure mail messsage formats floating around and making this the unified format Cheers David Gaon From owner-ietf-open-pgp Mon Aug 25 10:16:32 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA10333 for ietf-open-pgp-bks; Mon, 25 Aug 1997 10:16:32 -0700 (PDT) Received: from merit.edu (merit.edu [198.108.1.42]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA10329 for ; Mon, 25 Aug 1997 10:16:28 -0700 (PDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-02.dialip.mich.net [141.211.7.13]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA09181 for ; Mon, 25 Aug 1997 13:21:56 -0400 (EDT) Date: Mon, 25 Aug 97 16:49:05 GMT From: "William Allen Simpson" Message-ID: <6468.wsimpson@greendragon.com> To: ietf-open-pgp@imc.org Subject: Re: Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > From: "David Gaon" > >>>1. mandatory support for strong, open and unencumbered > >>>cryptographic algorithms. Other algorithms may be optionally > >>>specified, but will >>not be required for conformance. > > I disagree - There MUST NOT be any mandatory requirements for > algorithms, keys, ... Welcome to the IETF. We do not do things this way. > If they h ave compoatible capabilities, they will correspond, if they > do not, tough luck. The IETF requires _interoperable_ implementations for its Standards Process. That means we need to specify mandatory algorithms that all conformant implementations will use. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ietf-open-pgp Tue Aug 26 00:42:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA17513 for ietf-open-pgp-bks; Tue, 26 Aug 1997 00:42:57 -0700 (PDT) Received: from drum-damo.army.mil (root@DRUM-DAMO.ARMY.MIL [147.198.110.85]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA17509 for ; Tue, 26 Aug 1997 00:42:53 -0700 (PDT) Received: from [147.40.40.138] ([147.40.40.138]) by drum-damo.army.mil (8.7.5/8.7.3) with SMTP id CAA18714 for ; Tue, 26 Aug 1997 02:48:26 -0400 Received: from greenea.5sigcmd.army.mil by [147.40.40.138] for ietf-open-pgp@imc.org; Tue, 26 Aug 97 09:48:19 DST Message-Id: <3.0.3.32.19970826094816.007c6d80@[127.0.0.1]> X-Homepage: X-PGP-KeyId: pub 1083 0x78CD4329 X-PGP-Fingerprint: A3 57 37 48 54 88 FE 4A D6 81 C0 74 DA 00 A6 F7 X-Sender: agreene@[127.0.0.1] X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 26 Aug 1997 09:48:16 +0200 To: ietf-open-pgp@imc.org From: "Anthony E. Greene" Subject: Re: Open-PGP Charter In-Reply-To: <9707258725.AA872533046@ncr.disa.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- At 11:07 25-08-1997 EST, David Gaon wrote: > Allen Simpson wrote: > >>>1. mandatory support for strong, open and unencumbered > >>>cryptographic algorithms. Other algorithms may be optionally > >>>specified, but will >>not be required for conformance. > > I disagree - There MUST NOT be any mandatory requirements for > algorithms, keys, ... > If two correspondents need to correspond securely, they must first > establish their respective mail security capabilities (ie find out > what they can receive) through the use of other relevant mail > capabilities such as Directories. > If they h ave compoatible capabilities, they will correspond, if they > do not, tough luck. This is no problem for e-commerce because I > expect commercial enterprises will implement a multitude of security > capabilities to satisfy their cusdtomers. I think specifying at least one algorithm and key length/format should be a minimum requirement for interoperability. These minimums should be met with freely available algorithms. If we don't specify a common denominator then marketing forces, not technical merit, will select a defacto common denominator for us. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: cp850 Comment: Anthony E. Greene pub 1083 0x78cd4329 iQCdAwUBNAKKKkRUP9V4zUMpAQF8qAQ7BF6a3qeLLJjUssYq9pVFBvfmkKldpar0 D4Z9QuYNm1nBHhkPR7l+O+FBVMzFDNgZBZmGHhTZ/2t4YEdSg0de5hMhoMc3KiTK 8B8H70RtVLMnCwdSO2Yt68dI/gT9BgUJHLjdNdFVXliN6mefSUrYU0rLm3YKsRZI qHjhm9xbgtUqq8rPNsChkg== =17HH -----END PGP SIGNATURE----- From owner-ietf-open-pgp Wed Aug 27 05:22:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA06756 for ietf-open-pgp-bks; Wed, 27 Aug 1997 05:22:11 -0700 (PDT) Received: from sinfonix.rz.tu-clausthal.de (uA314tpvCVxBXNL6Hb+yeIE8gK0Qk+iL@sinfonix.rz.tu-clausthal.de [139.174.253.19]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA06751 for ; Wed, 27 Aug 1997 05:22:06 -0700 (PDT) Received: from modem3.slip.tu-clausthal.de (modem3.slip.tu-clausthal.de [139.174.7.3]) by sinfonix.rz.tu-clausthal.de (8.8.7/8.8.7) with SMTP id OAA11527 for ; Wed, 27 Aug 1997 14:27:28 +0200 (MET DST) Message-Id: <1.5.4.16.19970827122725.2f7fd380@pop.rz.tu-clausthal.de> X-No-Archive: Yes X-Sender: pehw@pop.rz.tu-clausthal.de X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Aug 1997 14:27:25 +0200 To: ietf-open-pgp@imc.org From: Hagen Wollert Subject: Re: mandatory requirements Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hello to all, at 11:07 25.08.97 EST David Gaon wrote: > Allen Simpson wrote: > >>>1. mandatory support for strong, open and unencumbered > >>>cryptographic algorithms. Other algorithms may be optionally > >>>specified, but will >>not be required for conformance. > > I disagree - There MUST NOT be any mandatory requirements for > algorithms, keys, ... I agree - but - though it sounds ridiculous - this feature should be implied in an ordered manner by choosing 'user agreed' in the algorithm field. > How about: > ""3. Gov and legislative policies from any country SHALL NOT be > considered nor shall they be caused to impact the specifications"" > > I think this what you intend! Gov policy should not be considered in any way ! I'd even have problems with a gov. approved key authentification as this might lead to a 'soft take-over'. CU, Hagen -- _____________________________________________________________________ Hagen Wollert h.wollert@tu-clausthal.de PGPed E-Mail welcome - public key available on most key-servers 2048/BBAF99CD MD5: 11 AD A2 70 67 0A 32 CA 34 D8 F0 CE 67 8A B7 A1 From owner-ietf-open-pgp Thu Aug 28 13:59:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA16407 for ietf-open-pgp-bks; Thu, 28 Aug 1997 13:59:45 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA16403 for ; Thu, 28 Aug 1997 13:59:41 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id OAA14841; Thu, 28 Aug 1997 14:05:23 -0700 (PDT) Message-Id: <3.0.2.32.19970828140951.00991a40@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 28 Aug 1997 14:09:51 -0700 To: ietf-open-pgp@imc.org From: Charles Breed Subject: UserID/Auth Field in Open-PGP certs Cc: metacert@pgp.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Open-PGP certificates should support both... 1) Identity 2) Autherization wrt Identity, Open-PGP should have the ability to handle other types of naming conventions than just the usual RFC822. In order to preserve previous implementations, we should make a new packet type that would be the new Generic Name packet. The UserID field (currently a 255 charater octet string) could handle other types, such as... OpenPGPGenericName ::= CHOICE { otherName [0] INSTANCE OF OTHER-NAME, rfc822Name [1] 255 Octet String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER } the OCTET STRING containing the IP-Address "123.124.125.126" should be coded like: '7B7C7D7E'H | | | | 123 | | | 124 | | 125 | 126 From owner-ietf-open-pgp Thu Aug 28 17:49:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA18690 for ietf-open-pgp-bks; Thu, 28 Aug 1997 17:49:26 -0700 (PDT) Received: from brahma.sics.se (brahma.sics.se [193.10.66.43]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA18682 for ; Thu, 28 Aug 1997 17:49:21 -0700 (PDT) Received: from anhur.sics.se by brahma.sics.se (8.7.3/SICS) with ESMTP id CAA04827; Fri, 29 Aug 1997 02:54:54 +0200 (MET DST) Received: from assaris.sics.se by anhur.sics.se (8.7.3/SICS-client) with ESMTP id CAA25705; Fri, 29 Aug 1997 02:54:53 +0200 (MET DST) Received: (from assar@localhost) by assaris.sics.se (8.8.5/8.8.5) id CAA13006; Fri, 29 Aug 1997 02:56:00 +0200 (MET DST) To: Charles Breed Cc: ietf-open-pgp@imc.org, metacert@pgp.com Subject: Re: UserID/Auth Field in Open-PGP certs References: <3.0.2.32.19970828140951.00991a40@mail.pgp.com> Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 29 Aug 1997 02:55:59 +0200 In-Reply-To: Charles Breed's message of Thu, 28 Aug 1997 14:09:51 -0700 Message-ID: <5lk9h5x0ww.fsf@assaris.sics.se> Lines: 19 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Charles Breed writes: > The UserID field (currently a 255 charater octet string) > could handle other types, such as... > > OpenPGPGenericName ::= CHOICE { > otherName [0] INSTANCE OF OTHER-NAME, > rfc822Name [1] 255 Octet String, > dNSName [2] IA5String, > x400Address [3] ORAddress, > directoryName [4] Name, > ediPartyName [5] EDIPartyName, > uniformResourceIdentifier [6] IA5String, > iPAddress [7] OCTET STRING, > registeredID [8] OBJECT IDENTIFIER } Do you actually propose using an ASN.1-related format or did you just happen to write it in this format? /assar From owner-ietf-open-pgp Fri Aug 29 06:19:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA26651 for ietf-open-pgp-bks; Fri, 29 Aug 1997 06:19:51 -0700 (PDT) Received: from mailhub.amaranth.com (root@mailhub.amaranth.com [209.37.228.4]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA26647 for ; Fri, 29 Aug 1997 06:19:47 -0700 (PDT) Received: from mailhub.amaranth.com (ppp52.pensacola.com [209.37.228.52]) by mailhub.amaranth.com (8.8.5/8.8.5) with SMTP id IAA32057; Fri, 29 Aug 1997 08:32:44 -0500 Message-Id: <199708291332.IAA32057@mailhub.amaranth.com> From: "William H. Geiger III" Date: Fri, 29 Aug 97 08:12:01 -0400 To: Charles Breed In-Reply-To: <3.0.2.32.19970828140951.00991a40@mail.pgp.com> Cc: ietf-open-pgp@imc.org, metacert@pgp.com Subject: Re: UserID/Auth Field in Open-PGP certs X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.32 b33 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <3.0.2.32.19970828140951.00991a40@mail.pgp.com>, on 08/28/97 at 04:09 PM, Charles Breed said: >Open-PGP certificates should support both... > 1) Identity > 2) Autherization >wrt Identity, Open-PGP should have the ability to handle other types of >naming conventions than just the usual RFC822. In order to preserve >previous implementations, we should make a new packet type that would be >the new Generic Name packet. >The UserID field (currently a 255 charater octet string) >could handle other types, such as... >OpenPGPGenericName ::= CHOICE { > otherName [0] INSTANCE OF OTHER-NAME, > rfc822Name [1] 255 Octet String, > dNSName [2] IA5String, > x400Address [3] ORAddress, > directoryName [4] Name, > ediPartyName [5] EDIPartyName, > uniformResourceIdentifier [6] IA5String, > iPAddress [7] OCTET STRING, > registeredID [8] OBJECT IDENTIFIER } >the OCTET STRING containing the IP-Address >"123.124.125.126" should be coded like: >'7B7C7D7E'H > | | | | >123 | | | > 124 | | > 125 | > 126 Hi Charles, I am a little confused by your proposal. Are you sugessting that: A) The User Interface should support creating the various Identifiers for the user. B1) These Identifiers should be stored in the current UserID field or B2) These Identifiers should be stored in a new Identifier field in addition to the UserID field or B3) Theses Identifiers should be stored in a new Identifier field as a replacement to the UserID field. C) Should there be a Identifier type field (0-F) or (00-FF)? Also should the RFC contain details on the formats of the various Identifiers or just pointers to other RFC's? Do you plan on any of these Identifiers to be manditory? If you could please elaborate on the use and implemntation of thes Identifier fields. Thanks, - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNAbBFY9Co1n+aLhhAQEwOQQAi/ZN/r5BA7ExoVrQotrBtcJBjTCzDZau U+bxqTDqnKGYXbP0htuXuYyfmDs6itwm1lHDwxBMGmvCYPpm/bqwCOfb3njou6Bu C0CppYuvLQyYezB9BifQI56MB8AntQdDmHEWIV+FEPagGBTgDoNLLK1MdIwUl654 W2o+kBqW19o= =XFbZ -----END PGP SIGNATURE----- From owner-ietf-open-pgp Fri Aug 29 13:04:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA01011 for ietf-open-pgp-bks; Fri, 29 Aug 1997 13:04:13 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA01007 for ; Fri, 29 Aug 1997 13:04:09 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id NAA01122 for ; Fri, 29 Aug 1997 13:09:56 -0700 (PDT) Message-Id: <3.0.2.32.19970829131427.00914e10@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 29 Aug 1997 13:14:27 -0700 To: ietf-open-pgp@imc.org From: Charles Breed Subject: Re: UserID/Auth Field in Open-PGP certs In-Reply-To: <199708291332.IAA32057@mailhub.amaranth.com> References: <3.0.2.32.19970828140951.00991a40@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hello William, I launched this message on UserID naming conventions to add 'some' type of structure to the existing UserID 'packet' field. The MUA - User I/F would not be required to 'conform', but an intelligent client for corp. use, might want more structure (with some guidlines). I would NOT create a new UserID Field. My initial objective here, is to measure the level of interest in adding additional convenstions. If there is interest, I'll submit a more detailed explanation. CB At 08:12 AM 8/29/97 -0400, William H. Geiger III wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >In <3.0.2.32.19970828140951.00991a40@mail.pgp.com>, on 08/28/97 > at 04:09 PM, Charles Breed said: > >>Open-PGP certificates should support both... >> 1) Identity >> 2) Autherization > >>wrt Identity, Open-PGP should have the ability to handle other types of >>naming conventions than just the usual RFC822. In order to preserve >>previous implementations, we should make a new packet type that would be >>the new Generic Name packet. > >>The UserID field (currently a 255 charater octet string) >>could handle other types, such as... > >>OpenPGPGenericName ::= CHOICE { >> otherName [0] INSTANCE OF OTHER-NAME, >> rfc822Name [1] 255 Octet String, >> dNSName [2] IA5String, >> x400Address [3] ORAddress, >> directoryName [4] Name, >> ediPartyName [5] EDIPartyName, >> uniformResourceIdentifier [6] IA5String, >> iPAddress [7] OCTET STRING, >> registeredID [8] OBJECT IDENTIFIER } > >>the OCTET STRING containing the IP-Address >>"123.124.125.126" should be coded like: >>'7B7C7D7E'H >> | | | | >>123 | | | >> 124 | | >> 125 | >> 126 > > >Hi Charles, > >I am a little confused by your proposal. > >Are you sugessting that: > >A) The User Interface should support creating the various Identifiers for >the user. > >B1) These Identifiers should be stored in the current UserID field or B2) >These Identifiers should be stored in a new Identifier field in addition >to the UserID field or B3) Theses Identifiers should be stored in a new >Identifier field as a replacement to the UserID field. > >C) Should there be a Identifier type field (0-F) or (00-FF)? > > >Also should the RFC contain details on the formats of the various >Identifiers or just pointers to other RFC's? > >Do you plan on any of these Identifiers to be manditory? > >If you could please elaborate on the use and implemntation of thes >Identifier fields. > >Thanks, > >- -- >- --------------------------------------------------------------- >William H. Geiger III http://www.amaranth.com/~whgiii >Geiger Consulting Cooking With Warp 4.0 > >Author of E-Secure - PGP Front End for MR/2 Ice >PGP & MR/2 the only way for secure e-mail. >OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html >- --------------------------------------------------------------- > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.3a >Charset: cp850 >Comment: Registered_User_E-Secure_v1.1b1_ES000000 > >iQCVAwUBNAbBFY9Co1n+aLhhAQEwOQQAi/ZN/r5BA7ExoVrQotrBtcJBjTCzDZau >U+bxqTDqnKGYXbP0htuXuYyfmDs6itwm1lHDwxBMGmvCYPpm/bqwCOfb3njou6Bu >C0CppYuvLQyYezB9BifQI56MB8AntQdDmHEWIV+FEPagGBTgDoNLLK1MdIwUl654 >W2o+kBqW19o= >=XFbZ >-----END PGP SIGNATURE----- > > > From owner-ietf-open-pgp Fri Aug 29 13:06:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA01057 for ietf-open-pgp-bks; Fri, 29 Aug 1997 13:06:37 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA01052 for ; Fri, 29 Aug 1997 13:06:34 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id NAA01177 for ; Fri, 29 Aug 1997 13:12:21 -0700 (PDT) Message-Id: <3.0.2.32.19970829131651.00b99100@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 29 Aug 1997 13:16:51 -0700 To: ietf-open-pgp@imc.org From: Charles Breed Subject: Re: UserID/Auth Field in Open-PGP certs In-Reply-To: <5lk9h5x0ww.fsf@assaris.sics.se> References: <3.0.2.32.19970828140951.00991a40@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Assar, I think we should avoid ASN.1 encoding rules at all cost, BUT if we are to do anything with a native X.509 cert... CB At 02:55 AM 8/29/97 +0200, Assar Westerlund wrote: >Charles Breed writes: >> The UserID field (currently a 255 charater octet string) >> could handle other types, such as... >> >> OpenPGPGenericName ::= CHOICE { >> otherName [0] INSTANCE OF OTHER-NAME, >> rfc822Name [1] 255 Octet String, >> dNSName [2] IA5String, >> x400Address [3] ORAddress, >> directoryName [4] Name, >> ediPartyName [5] EDIPartyName, >> uniformResourceIdentifier [6] IA5String, >> iPAddress [7] OCTET STRING, >> registeredID [8] OBJECT IDENTIFIER } > >Do you actually propose using an ASN.1-related format or did you just >happen to write it in this format? > >/assar > > From owner-ietf-open-pgp Fri Aug 29 13:33:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA01367 for ietf-open-pgp-bks; Fri, 29 Aug 1997 13:33:15 -0700 (PDT) Received: from mailhub.amaranth.com (root@mailhub.amaranth.com [209.37.228.4]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA01363 for ; Fri, 29 Aug 1997 13:33:11 -0700 (PDT) Received: from mailhub.amaranth.com (ppp63.pensacola.com [209.37.228.63]) by mailhub.amaranth.com (8.8.5/8.8.5) with SMTP id PAA05440; Fri, 29 Aug 1997 15:46:16 -0500 Message-Id: <199708292046.PAA05440@mailhub.amaranth.com> From: "William H. Geiger III" Date: Fri, 29 Aug 97 15:31:25 -0400 To: Charles Breed In-Reply-To: <3.0.2.32.19970829131427.00914e10@mail.pgp.com> Cc: ietf-open-pgp@imc.org Subject: Re: UserID/Auth Field in Open-PGP certs X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.32 b33 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <3.0.2.32.19970829131427.00914e10@mail.pgp.com>, on 08/29/97 at 01:14 PM, Charles Breed said: > Hello William, > I launched this message on UserID naming conventions to add 'some' > type of structure to the existing UserID 'packet' field. The MUA - > User I/F would not be required to 'conform', but an intelligent > client for corp. use, might want more structure (with some guidlines). > I would NOT create a new UserID Field. My initial objective here, is > to measure the level of interest in adding additional convenstions. > If there is interest, I'll submit a more detailed explanation. I would be intrested in seeing this advanced. I would like to see PGP give the users options to enter different types of UserID's with some built in format validity checking. There should also be a UserID type field though I imagine that this would cause compatibility problems with previous versions. There may be a way this could be added without adversely effecting backward compatiability. Could use the first 2 bytes of the UserID field and assign them as a type field but limit their values to non-typeable values (values 00x-0Fx are not likely to be found in a current userid). I would have killed to have this implemented in the PGP key format when I was doing my PGP integration work. Would have saved alot of jumping through hoops for matching e-mail addresses to keys in my e-mail applications. - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNAcmqI9Co1n+aLhhAQFPBQQAyPmpxOlv71NSm4G0vJhOUCBzc6hQ6Xhq O5LltyEOPoTG8rF7OKkUcjgS8ePhygK1e7XXjCD7mZgeGI4Imi0dRBmnhAddZKmt A1XVanoJN8m2QPScQoFw7c4gfmxQmRf9M4cUCM6AlN2/rtwIxLPCRjoZlLaTXFQY EAFcJGl2MIA= =gs3t -----END PGP SIGNATURE----- From owner-ietf-open-pgp Sat Aug 30 12:56:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA09920 for ietf-open-pgp-bks; Sat, 30 Aug 1997 12:56:50 -0700 (PDT) Received: from merit.edu (merit.edu [198.108.1.42]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA09916 for ; Sat, 30 Aug 1997 12:56:46 -0700 (PDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-16.dialip.mich.net [141.211.7.27]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA20174 for ; Sat, 30 Aug 1997 16:02:28 -0400 (EDT) Date: Sat, 30 Aug 97 19:02:50 GMT From: "William Allen Simpson" Message-ID: <6501.wsimpson@greendragon.com> To: ietf-open-pgp@imc.org Subject: Re: UserID/Auth Field in Open-PGP certs Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > From: Charles Breed > wrt Identity, Open-PGP should have the ability to handle other > types of naming conventions than just the usual RFC822. In order > to preserve previous implementations, we should make a new packet > type that would be the new Generic Name packet. > I agree. That is, the "User" element should remain the same, an undifferentiated byte-string. The new "Name" element should have some version and type field in it. But the way I'd recommend doing that is with the SPKI-SDSI "(name ...)" construct. Thus, the field could be used in both environments. BTW, AS..N...1 should be avoided at all costs. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ietf-open-pgp Mon Sep 1 01:05:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA21747 for ietf-open-pgp-bks; Mon, 1 Sep 1997 01:05:40 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id BAA21743 for ; Mon, 1 Sep 1997 01:05:36 -0700 (PDT) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 1 Sep 1997 09:11:11 +0100 Message-ID: <340A7872.F274AA7E@cs.ucl.ac.uk> Date: Mon, 01 Sep 1997 09:10:26 +0100 From: Ian Brown Organization: University College London X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: William Allen Simpson CC: ietf-open-pgp@imc.org Subject: Re: UserID/Auth Field in Open-PGP certs References: <6501.wsimpson@greendragon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk The option to add in X.509 information would certainly make it easier for open-pgp to gain acceptance in the corporate world... Ian. From owner-ietf-open-pgp Wed Sep 3 05:15:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA21695 for ietf-open-pgp-bks; Wed, 3 Sep 1997 05:15:20 -0700 (PDT) Received: from elektra.ultra.net (elektra.ultra.net [199.232.56.13]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA21686 for ; Wed, 3 Sep 1997 05:14:38 -0700 (PDT) Received: from mcfeeley.indusriver.com (pop3.indusriver.com [209.6.112.7]) by elektra.ultra.net (8.8.5/ult1.06) with SMTP id IAA18342 for ; Wed, 3 Sep 1997 08:20:08 -0400 (EDT) Received: from fakename.indusriver.com (209.6.112.80) by mcfeeley.indusriver.com (WorldMail 1.3.122) for ietf-open-pgp@imc.org; 3 Sep 1997 08:23:52 -0400 Message-Id: <3.0.3.32.19970902211304.0078bf2c@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 02 Sep 1997 21:13:04 -0400 To: ietf-open-pgp@imc.org From: Rodney Thayer Subject: key server lookup protocol? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Is there a document anywhere describing the key lookup protocol used in PGP 5? I see one of the firewalls I sometimes have to pass doesn't think it's a valid protocol and I'd like to swat the network manager at that site with a document... [No, I am *not* trying to introduce Mission Creep into the Open PGP WG charter.] From owner-ietf-open-pgp Wed Sep 3 07:38:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA23674 for ietf-open-pgp-bks; Wed, 3 Sep 1997 07:38:22 -0700 (PDT) Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA23667 for ; Wed, 3 Sep 1997 07:38:17 -0700 (PDT) Received: by janus.tor.securecomputing.com id <11649>; Wed, 3 Sep 1997 10:44:39 -0400 Message-Id: <97Sep3.104439edt.11649@janus.tor.securecomputing.com> To: Rodney Thayer cc: ietf-open-pgp@imc.org Subject: Re: key server lookup protocol? References: <3.0.3.32.19970902211304.0078bf2c@pop3.pn.com> In-reply-to: Your message of "Tue, 02 Sep 1997 21:13:04 -0400". <3.0.3.32.19970902211304.0078bf2c@pop3.pn.com> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 813 2054 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Wed, 3 Sep 1997 10:44:10 -0400 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk In message <3.0.3.32.19970902211304.0078bf2c@pop3.pn.com>, Rodney Thayer writes: > Is there a document anywhere describing the key lookup protocol used in PGP > 5? I see one of the firewalls I sometimes have to pass doesn't think it's > a valid protocol and I'd like to swat the network manager at that site with > a document... FWIW, it would have been *really* nice if this had been implemented as a WWW transaction, instead of as a separate protocol (on a separate port). Ah well; too late now, I guess. -- Harald. From owner-ietf-open-pgp Wed Sep 3 08:32:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA24326 for ietf-open-pgp-bks; Wed, 3 Sep 1997 08:32:20 -0700 (PDT) Received: from thoth.mch.sni.de (thoth.mch.sni.de [192.35.17.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA24322 for ; Wed, 3 Sep 1997 08:32:16 -0700 (PDT) Received: from D012S594.mch.sni.de (D012S594.mch.sni.de [139.23.80.237]) by thoth.mch.sni.de (8.8.7/8.8.7) with ESMTP id RAA09103 for ; Wed, 3 Sep 1997 17:38:19 +0200 (MDT) Received: from D012S437.mch.sni.de (D012S437.mch.sni.de [139.23.81.39]) by D012S594.mch.sni.de (8.8.5/8.8.5) with SMTP id PAA10188 for ; Wed, 3 Sep 1997 15:38:18 GMT Message-Id: <199709031538.PAA10188@D012S594.mch.sni.de> Received: by D012S437.mch.sni.de (4.1/MAIL-C@SNI-ASW-OS43) id AA27343; Wed, 3 Sep 97 17:38:16 MDT Date: Wed, 3 Sep 97 17:38:16 MDT From: bruecknr@D012S437.mch.sni.de (Frank Brueckner) To: ietf-open-pgp@imc.org Subject: Re: key server lookup protocol? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Rodney, Harald, > Is there a document anywhere describing the key lookup protocol used in PGP > 5? ... > FWIW, it would have been *really* nice if this had been implemented as a WWW > transaction, instead of as a separate protocol (on a separate port). Ah > well; too late now, I guess. Not too late ;-) PGP 5.0 sends the following request: "GET /pks/lookup?op=get&exact=on&search= HTTP/1.0" So you can run a CGI script acting as a Key Server (for retrieval), getting the key out from a data base (e.g. X.500) and sending back an application context like text/html or application/pgp-keys with the PGP Key in Ascii Armor. Frank. From owner-ietf-open-pgp Wed Sep 3 08:44:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA24499 for ietf-open-pgp-bks; Wed, 3 Sep 1997 08:44:34 -0700 (PDT) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA24495 for ; Wed, 3 Sep 1997 08:44:29 -0700 (PDT) Received: from beach.sctc.com (root@localhost) by beach.sctc.com with ESMTP id KAA29333; Wed, 3 Sep 1997 10:52:22 -0500 (CDT) Received: from cirdan (cirdan.sctc.com [172.17.65.99]) by beach.sctc.com with SMTP id KAA29328; Wed, 3 Sep 1997 10:52:21 -0500 (CDT) Message-Id: <3.0.3.32.19970903104833.00b2e460@mail.visi.com> X-Sender: zoo@mail.visi.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 03 Sep 1997 10:48:33 -0500 To: bruecknr@D012S437.mch.sni.de (Frank Brueckner), ietf-open-pgp@imc.org From: "david d `zoo' zuhn" Subject: Re: key server lookup protocol? In-Reply-To: <199709031538.PAA10188@D012S594.mch.sni.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >> FWIW, it would have been *really* nice if this had been implemented as a WWW >> transaction, instead of as a separate protocol (on a separate port). Ah >> well; too late now, I guess. >PGP 5.0 sends the following request: >"GET /pks/lookup?op=get&exact=on&search= HTTP/1.0" Great. So it is HTTP. Then maybe extend it a little bit so that HTTP proxy servers can be used (which is very often the case for people living behind corporate firewalls). -- - david d `zoo' zuhn -| Montana Rail Link/NP, circa 1995, in N scale -- zoo@armadillo.com --| www.armadillo.com/zoo/layout/ for info From owner-ietf-open-pgp Wed Sep 3 10:35:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA26153 for ietf-open-pgp-bks; Wed, 3 Sep 1997 10:35:25 -0700 (PDT) Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA26148 for ; Wed, 3 Sep 1997 10:35:19 -0700 (PDT) Received: by janus.tor.securecomputing.com id <11649>; Wed, 3 Sep 1997 13:41:41 -0400 Message-Id: <97Sep3.134141edt.11649@janus.tor.securecomputing.com> To: ietf-open-pgp@imc.org Subject: Re: key server lookup protocol? References: <199709031538.PAA10188@D012S594.mch.sni.de> In-reply-to: Your message of "Wed, 03 Sep 1997 19:38:16 -0400". <199709031538.PAA10188@D012S594.mch.sni.de> From: "C. Harald Koch" Date: Wed, 3 Sep 1997 13:41:12 -0400 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > Not too late ;-) > > PGP 5.0 sends the following request: > "GET /pks/lookup?op=get&exact=on&search= HTTP/1.0" Ah, good. I sit corrected. So now all we have to do is: a) get it back onto port 80 (both clients and keyservers) b) add HTTP proxy support (Both of these are implementation details :-) -- Harald From owner-ietf-open-pgp Wed Sep 3 11:22:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA26729 for ietf-open-pgp-bks; Wed, 3 Sep 1997 11:22:07 -0700 (PDT) Received: from dg-webo.webo.dg.com (dg-webo.us.dg.com [128.221.131.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id LAA26724 for ; Wed, 3 Sep 1997 11:22:01 -0700 (PDT) Received: from wellspring by dg-webo.webo.dg.com (5.4R3.10/dg-webo-v1) id AA14923; Wed, 3 Sep 1997 14:27:17 -0400 Received: from nrp by wellspring.us.dg.com (5.4R3.10/dg-gens08) id AA19738; Wed, 3 Sep 1997 14:27:15 -0400 Message-Id: <3.0.3.32.19970903142034.02f59948@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 03 Sep 1997 14:20:34 -0400 To: ietf-open-pgp@imc.org From: Rodney Thayer Subject: Re: key server lookup protocol? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk where is this documented? where is that goofy port number they use in PGP 5 documented? Has anyone tried this with a proxy server? This doesn't work with some firewalls. >Date: Wed, 3 Sep 97 17:38:16 MDT >From: bruecknr@D012S437.mch.sni.de (Frank Brueckner) >To: ietf-open-pgp@imc.org >Subject: Re: key server lookup protocol? >Sender: owner-ietf-open-pgp@imc.org > >Rodney, Harald, > > >> Is there a document anywhere describing the key lookup protocol used in PGP >> 5? ... > >> FWIW, it would have been *really* nice if this had been implemented as a WWW >> transaction, instead of as a separate protocol (on a separate port). Ah >> well; too late now, I guess. > >Not too late ;-) > >PGP 5.0 sends the following request: >"GET /pks/lookup?op=get&exact=on&search= HTTP/1.0" > >So you can run a CGI script acting as a Key Server (for retrieval), getting >the key out from a data base (e.g. X.500) and sending back an application >context like text/html or application/pgp-keys with the PGP Key in Ascii Armor. > > >Frank. > > > From owner-ietf-open-pgp Wed Sep 3 12:06:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA27314 for ietf-open-pgp-bks; Wed, 3 Sep 1997 12:06:43 -0700 (PDT) Received: from hobbes.orl.lmco.com (hobbes.orl.lmco.com [141.240.192.100]) by mail.proper.com (8.8.7/8.7.3) with SMTP id MAA27310 for ; Wed, 3 Sep 1997 12:06:39 -0700 (PDT) Date: Wed, 3 Sep 1997 15:11:40 -0400 (EDT) From: "A. Padgett Peterson P.E. Information Security" To: rodney@sabletech.com CC: ietf-open-pgp@imc.org Message-Id: <970903151140.202014ae@hobbes.orl.lmco.com> Subject: Re: key server lookup protocol? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >where is that goofy port number they use in PGP 5 documented? 11371 - was used by the original MIT server. Already suggested that PGP apply for a "assigned number" port under 1024. >Has anyone tried this with a proxy server? Not that I know of but not difficult - remote secure clients such as V-One's SmartWall already use other "goofy" ports as do any number of databases such as Oracle. >This doesn't work with some firewalls. SHTTP doesn't work with some firewalls. Warmly, Padgett From owner-ietf-open-pgp Wed Sep 3 12:27:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA27600 for ietf-open-pgp-bks; Wed, 3 Sep 1997 12:27:09 -0700 (PDT) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA27596 for ; Wed, 3 Sep 1997 12:27:05 -0700 (PDT) Received: from beach.sctc.com (root@localhost) by beach.sctc.com with ESMTP id OAA10992; Wed, 3 Sep 1997 14:35:06 -0500 (CDT) Received: from cirdan (cirdan.sctc.com [172.17.65.99]) by beach.sctc.com with SMTP id OAA10973; Wed, 3 Sep 1997 14:35:05 -0500 (CDT) Message-Id: <3.0.3.32.19970903143117.02ed4ac0@mail.visi.com> X-Sender: zoo@mail.visi.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 03 Sep 1997 14:31:17 -0500 To: "A. Padgett Peterson P.E. Information Security" , rodney@sabletech.com From: "david d `zoo' zuhn" Subject: Re: key server lookup protocol? Cc: ietf-open-pgp@imc.org In-Reply-To: <970903151140.202014ae@hobbes.orl.lmco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >>Has anyone tried this with a proxy server? >Not that I know of but not difficult - remote secure clients such as V-One's >SmartWall already use other "goofy" ports as do any number of databases >such as Oracle. Any firewall worth its salt should be capable of opening a TCP port on 11371, so thereby enabling access to the key server. No problems, but not a very good answer. It's not unreasonable to expect PGP to be able to cope with an HTTP proxy server, much as any Web browser does. I've done some testing to make sure that this works, and manual tests seem to work just fine. So the next step, and I'm going to see if I can do this in an afternoon (my attention span for coding these days), is to add explicit proxy support to the keyserver code in PGP itself. Once this is done, then the world of PGP users behind firewalls can utilize their already-working HTTP proxy server to access the various key server databases. >>This doesn't work with some firewalls. > >SHTTP doesn't work with some firewalls. What's the relevance of SHTTP? -- - david d `zoo' zuhn -| Montana Rail Link/NP, circa 1995, in N scale -- zoo@armadillo.com --| www.armadillo.com/zoo/layout/ for info From owner-ietf-open-pgp Wed Sep 3 12:55:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA27856 for ietf-open-pgp-bks; Wed, 3 Sep 1997 12:55:36 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA27847 for ; Wed, 3 Sep 1997 12:55:32 -0700 (PDT) Received: by brickwall.ceddec.com id <32258>; Wed, 3 Sep 1997 16:01:22 -0400 Date: Wed, 3 Sep 1997 16:00:44 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: Rodney Thayer cc: ietf-open-pgp@imc.org Subject: Re: key server lookup protocol? In-Reply-To: <3.0.3.32.19970903142034.02f59948@pop3.pn.com> Message-Id: <97Sep3.160122edt.32258@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wed, 3 Sep 1997, Rodney Thayer wrote: > where is this documented? It isn't, but is obvious from a source or packet sniffer > where is that goofy port number they use in PGP 5 documented? Most keyservers (e.g. mit) use that same port number, you don't notice it unless you look at the URL, so it is a case of an informal convention being change into a specification. >From my autolookup script which long predated pgp5.0: geturl http://swissnet.ai.mit.edu:11371/pks/lookup\?op=get\&search=0x$i > Has anyone tried this with a proxy server? Yes, but you have to tell the http proxy to work on the goofy port number, or enable that port number to pass through. > This doesn't work with some firewalls. It should be socksifiable, and the rest work as above. From owner-ietf-open-pgp Wed Sep 3 13:25:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA28150 for ietf-open-pgp-bks; Wed, 3 Sep 1997 13:25:28 -0700 (PDT) Received: from dg-webo.webo.dg.com (dg-webo.us.dg.com [128.221.131.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id NAA28145 for ; Wed, 3 Sep 1997 13:25:23 -0700 (PDT) Received: from wellspring by dg-webo.webo.dg.com (5.4R3.10/dg-webo-v1) id AA00113; Wed, 3 Sep 1997 16:30:57 -0400 Received: from nrp by wellspring.us.dg.com (5.4R3.10/dg-gens08) id AA26053; Wed, 3 Sep 1997 16:30:56 -0400 Message-Id: <3.0.3.32.19970903162711.02f6ed14@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 03 Sep 1997 16:27:11 -0400 To: ietf-open-pgp@imc.org From: Rodney Thayer Subject: Re: key server lookup protocol? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk The reason I want a document is so I can print it off and take it to the network manager of the offending firewall and swat him so he'll reconfigure it. "11371, I heard it on the net" doesn't seem like a sound formal specification to reference when asking someone to open a new hole in their firewall. >X-Sender: zoo@mail.visi.com >X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) >Date: Wed, 03 Sep 1997 14:31:17 -0500 >To: "A. Padgett Peterson P.E. Information Security" , > rodney@sabletech.com >From: "david d `zoo' zuhn" >Subject: Re: key server lookup protocol? >Cc: ietf-open-pgp@imc.org > >>>Has anyone tried this with a proxy server? >>Not that I know of but not difficult - remote secure clients such as V-One's >>SmartWall already use other "goofy" ports as do any number of databases >>such as Oracle. > >Any firewall worth its salt should be capable of opening a TCP port on >11371, so thereby enabling access to the key server. No problems, but >not a very good answer. > >It's not unreasonable to expect PGP to be able to cope with an HTTP >proxy server, much as any Web browser does. I've done some testing to >make sure that this works, and manual tests seem to work just fine. > >So the next step, and I'm going to see if I can do this in an afternoon >(my attention span for coding these days), is to add explicit proxy >support to the keyserver code in PGP itself. > >Once this is done, then the world of PGP users behind firewalls can >utilize their already-working HTTP proxy server to access the various >key server databases. > > >>>This doesn't work with some firewalls. >> >>SHTTP doesn't work with some firewalls. > >What's the relevance of SHTTP? > >-- >- david d `zoo' zuhn -| Montana Rail Link/NP, circa 1995, in N scale >-- zoo@armadillo.com --| www.armadillo.com/zoo/layout/ for info > > From owner-ietf-open-pgp Wed Sep 3 14:11:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA28738 for ietf-open-pgp-bks; Wed, 3 Sep 1997 14:11:09 -0700 (PDT) Received: from mailhub.amaranth.com (root@mailhub.amaranth.com [209.37.228.4]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA28734 for ; Wed, 3 Sep 1997 14:11:05 -0700 (PDT) Received: from mailhub.amaranth.com (ppp58.pensacola.com [209.37.228.58]) by mailhub.amaranth.com (8.8.5/8.8.5) with SMTP id QAA00034; Wed, 3 Sep 1997 16:21:24 -0500 Message-Id: <199709032121.QAA00034@mailhub.amaranth.com> From: "William H. Geiger III" Date: Wed, 03 Sep 97 16:07:20 -0400 To: Rodney Thayer In-Reply-To: <3.0.3.32.19970903162711.02f6ed14@pop3.pn.com> Cc: ietf-open-pgp@imc.org Subject: Re: key server lookup protocol? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.32 b33 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <3.0.3.32.19970903162711.02f6ed14@pop3.pn.com>, on 09/03/97 at 03:27 PM, Rodney Thayer said: >The reason I want a document is so I can print it off and take it to the >network manager of the offending firewall and swat him so he'll >reconfigure it. "11371, I heard it on the net" doesn't seem like a sound >formal specification to reference when asking someone to open a new hole >in their firewall. Well there is nothing formal on what port is being used. While most are using 11371 there are others using different ports including 80. This depends on the software configuration and software being used (not all servers are running the same software). Myself prefer having a flexible approach to the port being used by the server rather than having a set port. I can even see hi volumn servers using multiple ports for access (similar to what irc servers do). - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNA3HH49Co1n+aLhhAQH5NQP/dnKz9hx0sAKTpAt0j1mSRJ69vrT5unDa /gwxEzK5AnoiHaANPrureerEiIjWiK/hRZ60qKwCIYsES15fX1jbRcUmurEW35wn WxhfwT7Eq6PclPmQryj1oR6I25sV6dD3+lI8rQKk95bbuWmDOWtyQS4fZnVEl30z /UKltX1d/SU= =k1VE -----END PGP SIGNATURE----- From owner-ietf-open-pgp Wed Sep 3 14:06:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA28676 for ietf-open-pgp-bks; Wed, 3 Sep 1997 14:06:20 -0700 (PDT) Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.7]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA28672 for ; Wed, 3 Sep 1997 14:06:17 -0700 (PDT) Received: from aahz.jf.intel.com (aahz.jf.intel.com [192.198.161.2]) by mailbag.jf.intel.com (8.8.6/8.8.4) with ESMTP id OAA29258; Wed, 3 Sep 1997 14:14:23 -0700 (PDT) Received: (from batie@localhost) by aahz.jf.intel.com (8.8.5/8.8.5) id OAA18349; Wed, 3 Sep 1997 14:11:53 -0700 (PDT) Message-ID: <19970903141153.31392@aahz.jf.intel.com> Date: Wed, 3 Sep 1997 14:11:53 -0700 From: Alan Batie To: tzeruch@ceddec.com Cc: Rodney Thayer , ietf-open-pgp@imc.org Subject: Re: key server lookup protocol? References: <3.0.3.32.19970903142034.02f59948@pop3.pn.com> <97Sep3.160122edt.32258@brickwall.ceddec.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary="n2rw/3z4jIqBvZU5" X-Mailer: Mutt 0.76 In-Reply-To: <97Sep3.160122edt.32258@brickwall.ceddec.com>; from tzeruch@ceddec.com on Wed, Sep 03, 1997 at 04:00:44PM -0400 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --n2rw/3z4jIqBvZU5 Content-Type: text/plain; charset=us-ascii On Wed, Sep 03, 1997 at 04:00:44PM -0400, tzeruch@ceddec.com wrote: > > This doesn't work with some firewalls. > It should be socksifiable, and the rest work as above. I had our firewall guys set up a "transparent proxy" on port 11371 and when I tried to use it, pgpkeys.exe (the freeware download) said "receiving data", then after a long pause, died with an attempt to dereference a null pointer. I'm still analyzing the situation, but if it could be made to work with the regular http proxy, that would be much better. -- Alan Batie ------ What goes up, must come down. batie@aahz.jf.intel.com \ / Ask any system administrator. +1 503-264-8844 (voice) \ / --unknown D0 D2 39 0E 02 34 D6 B4 \/ 5A 41 21 8F 23 5F 08 9D --n2rw/3z4jIqBvZU5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNA3SmBCfrckvDwdpAQHuZwQAiYBPNdcAjBLWChacB6bmxJiMdLhEt2r6 ovE8lxPOxT1zCsAaUzPm1Q+qWoNG9rxszbKkzHs0e3JegrG49WtU4EeTEJylBvsC 9UO0hGF58pPwDHGyBWv+XkLix4xG5U1UE6ZHQr6yVTp+1Tw8WkXUxXWndKUdsbTn 0zerycH+K2w= =faDV -----END PGP SIGNATURE----- --n2rw/3z4jIqBvZU5-- From owner-ietf-open-pgp Wed Sep 3 15:40:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA29748 for ietf-open-pgp-bks; Wed, 3 Sep 1997 15:40:16 -0700 (PDT) Received: from rover.cygnus.com (rover.cygnus.com [192.80.44.65]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA29744 for ; Wed, 3 Sep 1997 15:40:11 -0700 (PDT) Received: (from marc@localhost) by rover.cygnus.com (8.8.5/8.6.12) id SAA12749; Wed, 3 Sep 1997 18:43:49 -0400 (EDT) To: Rodney Thayer , whgiii@amaranth.com, PADGETT@hobbes.orl.lmco.com Cc: ietf-open-pgp@imc.org Subject: Re: key server lookup protocol? References: <3.0.3.32.19970903142034.02f59948@pop3.pn.com> From: Marc Horowitz Date: 03 Sep 1997 18:43:48 -0400 In-Reply-To: Rodney Thayer's message of Wed, 03 Sep 1997 14:20:34 -0400 Message-ID: Lines: 55 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Rodney Thayer writes: >> where is this documented? History lesson: the pgp keyserver started as a perl cgi hack, which grew into a C hack, which grew into my undergraduate thesis, and then things got really out of control :-) If you want docs, look at and follow the thesis link (or the source link). The default port number isn't in there, but if it will make it easier for people to get holes in their firewalls, I can document it in the FAQ, or something. I suppose the next step is taking the relevant section from the thesis and formatting it as an i-d. >> where is that goofy port number they use in PGP 5 documented? It's the default in the installation. Remember, this used to be hack. >> Has anyone tried this with a proxy server? I don't see why it wouldn't work, if the proxy server is configured properly. >> This doesn't work with some firewalls. I'm completely unable to figure out how forbidding outbound TCP to high numbered ports enhances the security of any firewall. "A. Padgett Peterson P.E. Information Security" writes: >> 11371 - was used by the original MIT server. Already suggested that PGP >> apply for a "assigned number" port under 1024. Why under 1024? This would require that unix systems run the daemon as root, which is completely unnecessary. "William H. Geiger III" writes: >> Well there is nothing formal on what port is being used. While most are >> using 11371 there are others using different ports including 80. This >> depends on the software configuration and software being used (not all >> servers are running the same software). >> >> Myself prefer having a flexible approach to the port being used by the >> server rather than having a set port. I can even see hi volumn servers >> using multiple ports for access (similar to what irc servers do). My server code, at least, has a configuration file which allows the maintainer to specify the server port. It only supports one at a time, but there's already multiplexing code in there, so supporting more than one would be pretty easy. Marc From owner-ietf-open-pgp Wed Sep 3 22:12:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA03190 for ietf-open-pgp-bks; Wed, 3 Sep 1997 22:12:48 -0700 (PDT) Received: from drum-damo.army.mil (root@DRUM-DAMO.ARMY.MIL [147.198.110.85]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA03186 for ; Wed, 3 Sep 1997 22:12:43 -0700 (PDT) Received: from [147.40.40.138] ([147.40.40.138]) by drum-damo.army.mil (8.7.5/8.7.3) with SMTP id AAA01627 for ; Thu, 4 Sep 1997 00:22:17 -0400 Received: from greenea.5sigcmd.army.mil by [147.40.40.138] for ietf-open-pgp@imc.org; Thu, 04 Sep 97 07:17:32 DST Message-Id: <3.0.3.32.19970904071729.007e8100@[127.0.0.1]> X-Homepage: X-PGP-KeyId: pub 1083 0x78CD4329 X-PGP-Fingerprint: A3 57 37 48 54 88 FE 4A D6 81 C0 74 DA 00 A6 F7 X-Sender: agreene@[127.0.0.1] X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 04 Sep 1997 07:17:29 +0200 To: "Open-PGP List" From: "Anthony E. Greene" Subject: Re: key server lookup protocol? In-Reply-To: <199709031538.PAA10188@D012S594.mch.sni.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- At 17:38 03-09-1997 MDT, you wrote: >> FWIW, it would have been *really* nice if this had been implemented as a WWW >> transaction, instead of as a separate protocol (on a separate port). Ah >> well; too late now, I guess. > >Not too late ;-) > >PGP 5.0 sends the following request: >"GET /pks/lookup?op=get&exact=on&search= HTTP/1.0" The new keyserver works on port 11371. Most Web servers should be configurable to listen on this port. ***************************************************************** * Anthony E. Greene * * Use PGP -- Envelopes and Signatures for Email * * What is PGP?: * * My PGP Key: * * FREEWARE Win95 PGP 5.0: * ***************************************************************** -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: cp850 Comment: Anthony E. Greene pub 1083 0x78cd4329 iQCdAwUBNA5DfURUP9V4zUMpAQHIqgQ7BeODQVbhiYmkmRjrmc7mNNcfL3IpsqkM jHZUI0ClTghVHb9LZCKOoEyU2+qmP6gzN5yeZAhDPnsXoSIsadxnF+o9M1YfDVUK eTUeN5a2U62iTctp5rVK4ervyfBUjcROXauzycK0xQamUeqM9GBR41T0SoECb+ux LUrqgLBDshz0j/AR59aJMA== =OMyS -----END PGP SIGNATURE----- From owner-ietf-open-pgp Wed Sep 3 23:13:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA03602 for ietf-open-pgp-bks; Wed, 3 Sep 1997 23:13:46 -0700 (PDT) Received: from drum-damo.army.mil (root@DRUM-DAMO.ARMY.MIL [147.198.110.85]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA03598 for ; Wed, 3 Sep 1997 23:13:42 -0700 (PDT) Received: from [147.40.40.138] ([147.40.40.138]) by drum-damo.army.mil (8.7.5/8.7.3) with SMTP id BAA01676 for ; Thu, 4 Sep 1997 01:23:17 -0400 Received: from greenea.5sigcmd.army.mil by [147.40.40.138] for ietf-open-pgp@imc.org; Thu, 04 Sep 97 08:18:11 DST Message-Id: <3.0.3.32.19970904081808.007ed260@[127.0.0.1]> X-Homepage: X-PGP-KeyId: pub 1083 0x78CD4329 X-PGP-Fingerprint: A3 57 37 48 54 88 FE 4A D6 81 C0 74 DA 00 A6 F7 X-Sender: agreene@[127.0.0.1] X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 04 Sep 1997 08:18:08 +0200 To: ietf-open-pgp@imc.org From: "Anthony E. Greene" Subject: Re: key server lookup protocol? In-Reply-To: <3.0.3.32.19970903142034.02f59948@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 14:20 03-09-1997 -0400, you wrote: >where is this documented? > >where is that goofy port number they use in PGP 5 documented? > It's the default presented in the PGP 5.0 Preferences dialog. ***************************************************************** * Anthony E. Greene * * Use PGP -- Envelopes and Signatures for Email * * What is PGP?: * * My PGP Key: * * FREEWARE Win95 PGP 5.0: * ***************************************************************** From owner-ietf-open-pgp Thu Sep 4 15:39:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA16212 for ietf-open-pgp-bks; Thu, 4 Sep 1997 15:39:28 -0700 (PDT) Received: from doorstop.cs.auckland.ac.nz (root@doorstop.cs.auckland.ac.nz [130.216.35.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA16207 for ; Thu, 4 Sep 1997 15:39:23 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.33.9]) by doorstop.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id WAA04364 for ; Thu, 4 Sep 1997 22:46:21 +1200 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <87341312624346>; Fri, 5 Sep 1997 10:45:26 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-open-pgp@imc.org Subject: [Off-topic] Re: key server lookup protocol? Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Fri, 5 Sep 1997 10:45:26 (NZST) Message-ID: <87341312624346@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk tzeruch@ceddec.com writes: >On Wed, 3 Sep 1997, Rodney Thayer wrote: >>where is this documented? >It isn't, but is obvious from a source or packet sniffer This is like MITS Altair tech support when someone phoned asking for documentation: "You've got the schematic, what's the problem?". Peter. From owner-ietf-open-pgp Sun Sep 7 07:27:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA16573 for ietf-open-pgp-bks; Sun, 7 Sep 1997 07:27:05 -0700 (PDT) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA16569 for ; Sun, 7 Sep 1997 07:27:00 -0700 (PDT) Message-Id: <199709071427.HAA16569@mail.proper.com> Received: (qmail 6665 invoked from network); 7 Sep 1997 14:28:00 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 7 Sep 1997 14:28:00 -0000 Date: 8 Sep 1997 13:22:10 GMT From: Lindsay Mathieson Subject: PGP API To: ietf-open-pgp@imc.org X-Mailer: Black Paw Communications's MailCat for Win32 Beta Release Vs 2.6 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hi All, does anyone know of any docs for the Windows PGP 5.0 DLL's ? Thanks - Linz -- Lindsay Mathieson Black Paw Communications http://www.blackpaw.com/ From owner-ietf-open-pgp Sun Sep 7 21:19:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA21654 for ietf-open-pgp-bks; Sun, 7 Sep 1997 21:19:12 -0700 (PDT) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id VAA21650 for ; Sun, 7 Sep 1997 21:19:08 -0700 (PDT) Message-Id: <199709080419.VAA21650@mail.proper.com> Received: (qmail 13905 invoked from network); 8 Sep 1997 04:20:10 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 8 Sep 1997 04:20:10 -0000 CC: ietf-open-pgp@imc.org Date: 8 Sep 1997 3:13:32 GMT From: Lindsay Mathieson Subject: Re: PGP API To: "Robert C. Cline" X-Mailer: Black Paw Communications's MailCat for Win32 Beta Release Vs 2.6 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >>Docs? What docs do you mean? << Documentation on using the PGP DLL's from a program to encrypt/decrypt/sign messages, as well as manage the key databases. I wish to add PGP support to our email client. Cheers - Linz -- Lindsay Mathieson Black Paw Communications http://www.blackpaw.com/ From owner-ietf-open-pgp Mon Sep 8 03:07:02 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA26428 for ietf-open-pgp-bks; Mon, 8 Sep 1997 03:07:02 -0700 (PDT) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id DAA26424 for ; Mon, 8 Sep 1997 03:06:57 -0700 (PDT) Message-Id: <199709081006.DAA26424@mail.proper.com> Received: (qmail 27776 invoked from network); 8 Sep 1997 10:07:59 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 8 Sep 1997 10:07:59 -0000 CC: ietf-open-pgp@imc.org Date: 8 Sep 1997 9:1:18 GMT From: Lindsay Mathieson Subject: Re: PGP API To: "Anthony E. Greene" X-Mailer: Black Paw Communications's MailCat for Win32 Beta Release Vs 2.6 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >> For commerical use you'll have to purchase the DLL from PGP Inc. I'm sure they will provide docs and support. << I'd like to, but their dosn't seem to be any info on the PGP web site re this, and being a non-us company I suspect they would be restricted in what they could sell me. -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Release Vs 2.6, on September 8, 1997, in Win95 4.0 http://www.blackpaw.com/ From owner-ietf-open-pgp Mon Sep 8 07:28:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA28662 for ietf-open-pgp-bks; Mon, 8 Sep 1997 07:28:22 -0700 (PDT) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA28658 for ; Mon, 8 Sep 1997 07:28:19 -0700 (PDT) Received: from users.invweb.net (ppp71.pensacola.com [209.37.228.71]) by users.invweb.net (8.8.7/8.8.7) with SMTP id KAA18859; Mon, 8 Sep 1997 10:29:08 -0400 Message-Id: <199709081429.KAA18859@users.invweb.net> From: "William H. Geiger III" Date: Mon, 08 Sep 97 09:32:05 -0400 To: Lindsay Mathieson In-Reply-To: <199709081006.DAA26424@mail.proper.com> Cc: "Anthony E. Greene" , ietf-open-pgp@imc.org Subject: Re: PGP API X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.32 b33 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <199709081006.DAA26424@mail.proper.com>, on 09/08/97 at 09:01 AM, Lindsay Mathieson said: >>> >For commerical use you'll have to purchase the DLL from PGP Inc. I'm sure > they will provide docs and support. ><< >I'd like to, but their dosn't seem to be any info on the PGP web site re >this, and being a non-us company I suspect they would be restricted in >what they could sell me. I beleive that there is a PGP Developers Kit for the Windows platform for integrating PGP into application. Unfortunatly if you are outside of the US you are going to be SOL due to the ITAR/EAR restrictions. You could always goto: http://www.pgpi.com get the 5.0i source code and build your own dll's. I know that this is a PITA but this seems to be your only alternative at this time. - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNBP/FI9Co1n+aLhhAQElogQAnezjMqqJlGZgwEtCTPjs3jkIlSykN5Uw RcfxGA8M/3imj6vtRC/gUR9XZ/Sx9qupc9tc/vsl9CZC6JdamNEmI78FJ11v2PAZ XBECD8XCHVXvO5KPTsrJv6++V6HCRBELCG4W3P1wTnvPhX562WX9PdVBo7z/G5a1 smCaOZGCe3I= =zwg0 -----END PGP SIGNATURE----- From owner-ietf-open-pgp Tue Sep 9 17:24:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA23140 for ietf-open-pgp-bks; Tue, 9 Sep 1997 17:24:50 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA23136 for ; Tue, 9 Sep 1997 17:24:46 -0700 (PDT) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id RAA00937; Tue, 9 Sep 1997 17:25:53 -0700 (PDT) Message-Id: <3.0.2.32.19970909171925.009bf1c0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 09 Sep 1997 17:19:25 -0700 To: "C. Harald Koch" , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: key server lookup protocol? In-Reply-To: <97Sep3.134141edt.11649@janus.tor.securecomputing.com> References: <199709031538.PAA10188@D012S594.mch.sni.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 01:41 PM 9/3/97 -0400, C. Harald Koch wrote: > Not too late ;-) > > PGP 5.0 sends the following request: > "GET /pks/lookup?op=get&exact=on&search= HTTP/1.0" Ah, good. I sit corrected. So now all we have to do is: a) get it back onto port 80 (both clients and keyservers) b) add HTTP proxy support (Both of these are implementation details :-) Indeed. There's no reason it can't be on any port whatsoever. Now, with 5.5, we have an ldap server, which will make things a lot easier. We support the old HTTP one, but the ldap one is the way to go. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 From owner-ietf-open-pgp Tue Sep 9 19:44:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA24174 for ietf-open-pgp-bks; Tue, 9 Sep 1997 19:44:00 -0700 (PDT) Received: from [165.227.249.112] (buddhi.proper.com [165.227.249.112]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA24170 for ; Tue, 9 Sep 1997 19:43:56 -0700 (PDT) Message-Id: In-Reply-To: <3.0.2.32.19970909171925.009bf1c0@mail.pgp.com> References: <97Sep3.134141edt.11649@janus.tor.securecomputing.com> <199709031538.PAA10188@D012S594.mch.sni.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Sep 1997 19:45:12 -0700 To: ietf-open-pgp@imc.org From: Paul Hoffman / IMC Subject: The purpose of this mailing list Sender: owner-ietf-open-pgp@imc.org Precedence: bulk This mailing list is for discussion of the next-generation of PGP/MIME. We should be creating and discussing descriptions of that protocol. The discussions of the last few days (key server lookup protocol, API) are not really relevant to the OpenPGP spec. Disucssions about how a particular implementation of PGP work should be on the PGP developer's mailing list, not here. (I don't remember where that mailing list is, and it doesn't seem to be mentioned on the PGP, Inc. Web site, so if someone wants to pipe in with the address of that list, it would be very helpful.) --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-open-pgp Wed Sep 10 00:56:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA26518 for ietf-open-pgp-bks; Wed, 10 Sep 1997 00:56:48 -0700 (PDT) Received: from zinc.singnet.com.sg (zinc.singnet.com.sg [165.21.7.31]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA26513; Wed, 10 Sep 1997 00:56:39 -0700 (PDT) Received: from ts900-8706.singnet.com.sg (ts900-8706.singnet.com.sg [165.21.169.58]) by zinc.singnet.com.sg (8.8.7/8.8.7) with SMTP id PAA15607; Wed, 10 Sep 1997 15:57:31 +0800 (SGT) Received: by ts900-8706.singnet.com.sg with Microsoft Mail id <01BCBE02.616740A0@ts900-8706.singnet.com.sg>; Wed, 10 Sep 1997 15:58:29 +0800 Message-ID: <01BCBE02.616740A0@ts900-8706.singnet.com.sg> From: Steven Tay Beng Kuan To: "'Paul Hoffman / IMC'" Cc: "'ietf-open-pgp@imc.org'" Subject: RE: The purpose of this mailing list Date: Wed, 10 Sep 1997 15:57:52 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > ----- Original Message ----- > From: Paul Hoffman / IMC [SMTP:phoffman@imc.org] > Sent: Wednesday, September 10, 1997, 10:45:12 > To: ietf-open-pgp@imc.org > Subject: The purpose of this mailing list > > This mailing list is for discussion of the next-generation of PGP/MIME. We > should be creating and discussing descriptions of that protocol. > > The discussions of the last few days (key server lookup protocol, API) are > not really relevant to the OpenPGP spec. Disucssions about how a particular > implementation of PGP work should be on the PGP developer's mailing list, > not here. (I don't remember where that mailing list is, and it doesn't seem > to be mentioned on the PGP, Inc. Web site, so if someone wants to pipe in > with the address of that list, it would be very helpful.) > > --Paul E. Hoffman, Director > --Internet Mail Consortium > > > > > ----- End Of Original Message ----- Hi, PGP User Mailing List To subscribe to the digest, e-mail: pgp-digest-subscribe@joshua.rivertown.net Likewise- To unsubscribe to the digest, e-mail: pgp-digest-unsubscribe@joshua.rivertown.net To post to the list, e-mail: pgp-users@joshua.rivertown.net. Happy surfing. See u in the list. Steven Tay Beng Kuan [ ICQ: 1423100 ] SiteBuilder Member Level 2 [ Have you Sign my Guessbook ] Url: http://www.post1.com/~bkuan Email: bkuan@post1.com Send message to me with subject "send pgp" for PGP key Public Key also at http://www.post1.com/~bkuan/pgpkey.html From owner-ietf-open-pgp Wed Sep 10 05:56:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA00669 for ietf-open-pgp-bks; Wed, 10 Sep 1997 05:56:56 -0700 (PDT) Received: from elektra.ultra.net (elektra.ultra.net [199.232.56.13]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA00659; Wed, 10 Sep 1997 05:56:49 -0700 (PDT) Received: from mcfeeley.indusriver.com (pop3.indusriver.com [209.6.112.7]) by elektra.ultra.net (8.8.5/ult1.06) with SMTP id IAA03884; Wed, 10 Sep 1997 08:58:06 -0400 (EDT) Received: from ferguson.indusriver.com (209.6.112.80) by mcfeeley.indusriver.com (WorldMail 1.3.122); 10 Sep 1997 09:02:22 -0400 Message-Id: <3.0.3.32.19970910083503.006c4384@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 10 Sep 1997 08:35:03 -0400 To: phoffman@imc.org From: Rodney Thayer Subject: The purpose of this mailing list Cc: ietf-open-pgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry you found my posting off-topic. Since the charter process has not been completed yet (I believe it's going through due process, I am not worried) and since I was discussing a critical and undocumented aspect of the current and future technology I thought it was relevant. I think we have to allow some level of discussion of the state of the art in this forum or else we won't have a baseline as to where the next generation of PGP should go. The fact there is no public established developer list is exactly the point -- there are clusters of informal communities, and what we want to do is to get those pulled together in an IETF framework to move forward. Also, you seem to have waited an AWFULLY long time before speaking up. >Date: Tue, 9 Sep 1997 19:45:12 -0700 >To: ietf-open-pgp@imc.org >From: Paul Hoffman / IMC >Subject: The purpose of this mailing list >Sender: owner-ietf-open-pgp@imc.org > >This mailing list is for discussion of the next-generation of PGP/MIME. We >should be creating and discussing descriptions of that protocol. > >The discussions of the last few days (key server lookup protocol, API) are >not really relevant to the OpenPGP spec. Disucssions about how a particular >implementation of PGP work should be on the PGP developer's mailing list, >not here. (I don't remember where that mailing list is, and it doesn't seem >to be mentioned on the PGP, Inc. Web site, so if someone wants to pipe in >with the address of that list, it would be very helpful.) > >--Paul E. Hoffman, Director >--Internet Mail Consortium > > > > -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNBaXS4wpVk/gvJfqEQJCYACZAfhKtSfOrmmLaJbE3eZf6VfK7TMAn3Zj dvCls2TxkQ7+Y3H+NuK9czyY =UqBL -----END PGP SIGNATURE----- From owner-ietf-open-pgp Wed Sep 10 05:57:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA00671 for ietf-open-pgp-bks; Wed, 10 Sep 1997 05:57:01 -0700 (PDT) Received: from elektra.ultra.net (elektra.ultra.net [199.232.56.13]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA00660; Wed, 10 Sep 1997 05:56:50 -0700 (PDT) Received: from mcfeeley.indusriver.com (pop3.indusriver.com [209.6.112.7]) by elektra.ultra.net (8.8.5/ult1.06) with SMTP id IAA07665; Wed, 10 Sep 1997 08:58:07 -0400 (EDT) Received: from ferguson.indusriver.com (209.6.112.80) by mcfeeley.indusriver.com (WorldMail 1.3.122); 10 Sep 1997 09:02:23 -0400 Message-Id: <3.0.3.32.19970910084915.00770684@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 10 Sep 1997 08:49:15 -0400 To: phoffman@imc.org From: Rodney Thayer Subject: The purpose of this mailing list Cc: ietf-open-pgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry you found my posting off-topic. Since the charter process has not been completed yet (I believe it's going through due process, I am not worried) and since I was discussing a critical and undocumented aspect of the current and future technology I thought it was relevant. I think we have to allow some level of discussion of the state of the art in this forum or else we won't have a baseline as to where the next generation of PGP should go. The fact there is no public established developer list is exactly the point -- there are clusters of informal communities, and what we want to do is to get those pulled together in an IETF framework to move forward. Also, you seem to have waited an AWFULLY long time before speaking up. >Date: Tue, 9 Sep 1997 19:45:12 -0700 >To: ietf-open-pgp@imc.org >From: Paul Hoffman / IMC >Subject: The purpose of this mailing list >Sender: owner-ietf-open-pgp@imc.org > >This mailing list is for discussion of the next-generation of PGP/MIME. We >should be creating and discussing descriptions of that protocol. > >The discussions of the last few days (key server lookup protocol, API) are >not really relevant to the OpenPGP spec. Disucssions about how a particular >implementation of PGP work should be on the PGP developer's mailing list, >not here. (I don't remember where that mailing list is, and it doesn't seem >to be mentioned on the PGP, Inc. Web site, so if someone wants to pipe in >with the address of that list, it would be very helpful.) > >--Paul E. Hoffman, Director >--Internet Mail Consortium > > > > -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNBaXS4wpVk/gvJfqEQJCYACZAfhKtSfOrmmLaJbE3eZf6VfK7TMAn3Zj dvCls2TxkQ7+Y3H+NuK9czyY =UqBL -----END PGP SIGNATURE----- From owner-ietf-open-pgp Wed Sep 10 08:34:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA02195 for ietf-open-pgp-bks; Wed, 10 Sep 1997 08:34:54 -0700 (PDT) Received: from merit.edu (merit.edu [198.108.1.42]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA02191 for ; Wed, 10 Sep 1997 08:34:50 -0700 (PDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-02.dialip.mich.net [141.211.7.13]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA05467 for ; Wed, 10 Sep 1997 11:36:06 -0400 (EDT) Date: Wed, 10 Sep 97 15:18:36 GMT From: "William Allen Simpson" Message-ID: <6554.wsimpson@greendragon.com> To: ietf-open-pgp@imc.org Subject: Re: The purpose of this mailing list Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > From: Rodney Thayer > I think we have to allow some level of discussion of the state of the > art in this forum or else we won't have a baseline as to where the > next generation of PGP should go. > I agree. When will the _current_ PGP draft be done? I have a partial draft for streamlining PGP in the SPKI mold, but I've been awaiting the detailed and complete PGP 5 draft. A lot of things are not well specified. Or are we starting from a clean slate? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ietf-open-pgp Wed Sep 10 10:05:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA03657 for ietf-open-pgp-bks; Wed, 10 Sep 1997 10:05:00 -0700 (PDT) Received: from mailhub.amaranth.com (root@mailhub.amaranth.com [209.37.228.4]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA03651; Wed, 10 Sep 1997 10:04:56 -0700 (PDT) Received: from mailhub.amaranth.com (ppp4.dotstar.net [208.143.93.23]) by mailhub.amaranth.com (8.8.5/8.8.5) with SMTP id MAA06503; Wed, 10 Sep 1997 12:10:12 -0500 Message-Id: <199709101710.MAA06503@mailhub.amaranth.com> From: "William H. Geiger III" Date: Wed, 10 Sep 97 12:05:14 -0400 To: Rodney Thayer In-Reply-To: <3.0.3.32.19970910084915.00770684@pop3.pn.com> Cc: phoffman@imc.org, ietf-open-pgp@imc.org Subject: Re: The purpose of this mailing list X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.32 b33 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <3.0.3.32.19970910084915.00770684@pop3.pn.com>, on 09/10/97 at 07:49 AM, Rodney Thayer said: >Sorry you found my posting off-topic. Since the charter process has not >been completed yet (I believe it's going through due process, I am not >worried) and since I was discussing a critical and undocumented aspect >of the current and future technology I thought it was relevant. >I think we have to allow some level of discussion of the state of the >art in this forum or else we won't have a baseline as to where the next >generation of PGP should go. >The fact there is no public established developer list is exactly the >point -- there are clusters of informal communities, and what we want to >do is to get those pulled together in an IETF framework to move forward. >Also, you seem to have waited an AWFULLY long time before speaking up. I'll have to agree with Rodney here. :) IMHO the Public Key Servers are more improtant to the contiuned development and growth of PGP than any particular algortihm being used by PGP. From the nuber of posts here on the topic it seems that it is of great intrest to the members of the list. Perhaps we need to create a draft RFC and working group on PGP keyserver protocols as it seems the only ones making an decisions on this is PGP Inc. - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNBbG4o9Co1n+aLhhAQHCHgQApIGg2W8CzZL8DMZ3c6LkWlYbUycZsfL8 z1nKPR2kHBbL0UgX622OgZh0SoC3ShHoGUoubjZ7ucEicWSGl9g27KVpUe8KRDPQ XfOwI5hxl0XYfOxf0RlCPPN39ndgDSw6iC0Ps5O4LTU+EiT3NJelZLrMB1ZBW7t9 24olyZ555mg= =Wunh -----END PGP SIGNATURE----- From owner-ietf-open-pgp Wed Sep 10 10:13:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA03781 for ietf-open-pgp-bks; Wed, 10 Sep 1997 10:13:37 -0700 (PDT) Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by mail.proper.com (8.8.7/8.7.3) with SMTP id KAA03777 for ; Wed, 10 Sep 1997 10:13:28 -0700 (PDT) Received: from w.ic-public.utoronto.ca ([128.100.46.76]) by bureau6.utcc.utoronto.ca with SMTP id <160125(6)>; Wed, 10 Sep 1997 12:52:50 -0400 Date: Wed, 10 Sep 1997 12:53:20 -0400 From: To: ietf-open-pgp@imc.org Subject: handling of different encryption methods..? Message-ID: X-X-Sender: guerraro@mailbox96.utcc.utoronto.ca MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk ---------- Forwarded message ---------- With the advent of several different ways to encrypt & Sign pgp messages, i'd like to know if it might be a good idea to specify a preffered "method" which should be used in "answering" an encoded message. An example (using pgp 5.0 & Eudora Plug-in): 1.A encrypts & signs a message with RSA and sends it to B. 2.B decodes the message, and writes a reply to A's message 3.When message is processed by eudora/pgp a problem arises....A has two public keys..A RSA key and a DH/DSS key...which one should be used..? (one can decide to use both keys, and leave it up to A to decode...however A may "prefer" one method...) Thus, if it would be possible to encorporate a "preferred encrytion/signing method" then the selection of which key/encrytion method might be able to be done automatically... I mentioned this a while ago to the folks at pgp, and would be interested in hearing what the mailing list thinks... regards robert From owner-ietf-open-pgp Wed Sep 10 11:02:08 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA04204 for ietf-open-pgp-bks; Wed, 10 Sep 1997 11:02:08 -0700 (PDT) Received: from mailhub.amaranth.com (root@mailhub.amaranth.com [209.37.228.4]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA04200 for ; Wed, 10 Sep 1997 11:02:04 -0700 (PDT) Received: from mailhub.amaranth.com (ppp4.dotstar.net [208.143.93.23]) by mailhub.amaranth.com (8.8.5/8.8.5) with SMTP id NAA07295; Wed, 10 Sep 1997 13:07:20 -0500 Message-Id: <199709101807.NAA07295@mailhub.amaranth.com> From: "William H. Geiger III" Date: Wed, 10 Sep 97 12:27:36 -0400 To: In-Reply-To: Cc: ietf-open-pgp@imc.org Subject: Re: handling of different encryption methods..? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.32 b33 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In , on 09/10/97 at 11:53 AM, said: >---------- Forwarded message ---------- >With the advent of several different ways to encrypt & Sign pgp messages, >i'd like to know if it might be a good idea to specify a preffered >"method" which should be used in "answering" an encoded message. >An example (using pgp 5.0 & Eudora Plug-in): >1.A encrypts & signs a message with RSA and sends it to B. >2.B decodes the message, and writes a reply to A's message >3.When message is processed by eudora/pgp a problem arises....A has two >public keys..A RSA key and a DH/DSS key...which one should be used..? >(one can decide to use both keys, and leave it up to A to >decode...however A may "prefer" one method...) >Thus, if it would be possible to encorporate a "preferred >encrytion/signing method" then the selection of which key/encrytion >method might > be able to be done automatically... >I mentioned this a while ago to the folks at pgp, and would be interested >in hearing what the mailing list thinks... I have something like this with my current PGP implementation. Unfortunately it's not very automatic. My users have the ability to set a default key for an e-mail address. This was neccessary as quite often one will find multiple keys with the same e-mail address in the Userid's. Automatic determining of how to sign a message is tricky. - -- The simplest is just to use MD5/PGP2.6.x method of signing as everyone regardless of version can verify these signatures. - -- Use PGP/MIME and sign the message in parallel in both formats. This will cause problems with those unable to verify PGP/MIME signatures. - -- Clear sign the message using standard PGP 2.6.x format then PGP/MIME sign the message using the PGP 5.0 key. This would give the user the greatest flexibility but I am sure there will be a few that will squawk over this. :) - -- Lookup the receivers key and check and see what type it is then use a corresponding signature format. Much more work involved here as it would require communication with the servers for each signature. It also does not address the issue of a receiver having both types of keys nor the issue of signed messages going to a group of people. The current situation of PGP 2.6.x/RSA/MD5 & PGP 5.0/DSS/SHA1 is a real PITA. It has added quite a bit of complication to PGP integration efforts. - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNBbURY9Co1n+aLhhAQG7jwP/S7gepuvz1ssAP88NjkdDkiBwxXbloE3B 5ESnTQjrHvoFNl0IsDBDK8tLPXIn25lA8/U5MPIpqgKnERj17bkWQdXcTxUADtyc jbvj24fAgAm8gHDLr7Eptd4lxoWtk/gVtPsojkDOHVx/2x+K3d2CbjRi4kv3/YFZ f9V6OkVKp88= =YeiL -----END PGP SIGNATURE----- From owner-ietf-open-pgp Wed Sep 10 14:31:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA06832 for ietf-open-pgp-bks; Wed, 10 Sep 1997 14:31:14 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA06827; Wed, 10 Sep 1997 14:31:10 -0700 (PDT) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id OAA16209; Wed, 10 Sep 1997 14:32:29 -0700 (PDT) Message-Id: <3.0.2.32.19970910142556.009c5740@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 10 Sep 1997 14:25:56 -0700 To: Paul Hoffman / IMC , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: The purpose of this mailing list In-Reply-To: References: <3.0.2.32.19970909171925.009bf1c0@mail.pgp.com> <97Sep3.134141edt.11649@janus.tor.securecomputing.com> <199709031538.PAA10188@D012S594.mch.sni.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 07:45 PM 9/9/97 -0700, Paul Hoffman / IMC wrote: This mailing list is for discussion of the next-generation of PGP/MIME. We should be creating and discussing descriptions of that protocol. The discussions of the last few days (key server lookup protocol, API) are not really relevant to the OpenPGP spec. Disucssions about how a particular implementation of PGP work should be on the PGP developer's mailing list, not here. (I don't remember where that mailing list is, and it doesn't seem to be mentioned on the PGP, Inc. Web site, so if someone wants to pipe in with the address of that list, it would be very helpful.) I disagree completely. This is *NOT* the mailing list for the next-generation of PGP-MIME. This is the mailing list for OpenPGP. That's why it's called the "ietf-open-pgp" mailing list. I think that it's completely germane for the OpenPGP list to discuss the OpenPGP spec, including key server protocols. What purpose do you think the OpenPGP mailing list should be serving other than discussions of OpenPGP? Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 From owner-ietf-open-pgp Thu Sep 11 02:57:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA14066 for ietf-open-pgp-bks; Thu, 11 Sep 1997 02:57:04 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id CAA14061; Thu, 11 Sep 1997 02:56:55 -0700 (PDT) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 11 Sep 1997 10:57:37 +0100 Message-ID: <3417C036.2A9B213C@cs.ucl.ac.uk> Date: Thu, 11 Sep 1997 10:56:06 +0100 From: Ian Brown Organization: University College London X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: "William H. Geiger III" CC: Rodney Thayer , phoffman@imc.org, ietf-open-pgp@imc.org Subject: Re: The purpose of this mailing list References: <199709101710.MAA06503@mailhub.amaranth.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- William H. Geiger wrote: > Perhaps we need to create a draft RFC and working group on PGP keyserver > protocols as it seems the only ones making an decisions on this is PGP > Inc. Robert Guerra wrote: > With the advent of several different ways to encrypt & Sign pgp messages, > i'd like to know if it might be a good idea to specify a preffered "method" > which should be used in "answering" an encoded message. Here's an ideal opportunity to tie both of these threads together. A next generation keyserver could store multiple keys for a user, but be able to specify their preferred one. This would allow both selection of algorithm and preferred key for receiving correspondence, while allowing other keys needed to check signatures etc. to be retrieved if necessary. Ian :D -----BEGIN PGP SIGNATURE----- Version: Cryptix 2.21 iQCVAgUANBfAPZpi0bQULdFRAQF+/QP/fXrqwBYH4YTKV2EhUyyNpuKnx8BCLT5Wn3kAfxAqe9TA MiDiOrJu2u053YVj7vg3rQ8TMdFAX2QiOZVMkJFs/VkrQfeKPP/yDMmAcZgu5x939ks9pujDjUj+ OhcFqns5qZXcwsFMx6uMwf23Rw2rMjMlc1B8MfxtoFZrHWpkEQk= =jMEW -----END PGP SIGNATURE----- From owner-ietf-open-pgp Thu Sep 11 14:32:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA22613 for ietf-open-pgp-bks; Thu, 11 Sep 1997 14:32:42 -0700 (PDT) Received: from hq.vni.net (root@hq.vni.net [205.252.27.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA22608; Thu, 11 Sep 1997 14:32:36 -0700 (PDT) Received: from PCSLIP.ieca.com (rock-aa-018.vni.net [206.161.70.218]) by hq.vni.net (8.8.5/8.8.5) with SMTP id RAA10330; Thu, 11 Sep 1997 17:33:43 -0400 (EDT) Message-Id: <199709112133.RAA10330@hq.vni.net> Comments: Authenticated sender is From: "Bonatti Chris" Organization: IECA, Inc. To: Ian Brown Date: Thu, 11 Sep 1997 17:31:25 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: The purpose of this mailing list Reply-to: bonattic@ieca.com CC: rodney@sabletech.com, phoffman@imc.org, ietf-open-pgp@imc.org In-reply-to: <3417C036.2A9B213C@cs.ucl.ac.uk> X-PM-Encryptor: PM-CRYPTPGP, 1 X-mailer: Pegasus Mail for Win32 (v2.53/R1) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Thu, 11 Sep 1997 10:56:06 +0100, Ian Brown wrote: > > Here's an ideal opportunity to tie both of these threads > together. A next generation keyserver could store multiple keys > for a user, but be able to specify their preferred one. This > would allow both selection of algorithm and preferred key for > receiving correspondence, while allowing other keys needed to > check signatures etc. to be retrieved if necessary. > This is the best idea yet. It kills 2 bird with one stone. This approach would suggest a requirement for certificate structures. BTW, I've seen some messages regarding X.509 certificates posted (both pro and con). I guess my feeling is that whatever we develop should be flexible enough to work with a variety of public key management schemes. Large organizations are probably going to benefit from hierarchical certificate management offered by a X.509. However, the level of infrastructure required can be very hard to bootstrap. I would not want either side of this issue to become a barrier to Open-PGP acceptance. Thus I think our trust model should be flexible enough to embrace X.509 and web-of-trust. Chris --------------------------------------------------------------- | International Electronic Communication Analysts, Inc. | | Christopher D. Bonatti 9010 Edgepark Road | | Vice-president Vienna, Virginia 22182 | | bonattic@ieca.com Tel: 301-212-9428 Fax: 703-506-8377 | | PGP public key available from "http://www.ieca.com/" | --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAgUBNBgc3a8wqXqPmmVZAQF2vQP+NRWSGYeJQQW3tS3skXt9KEyKMM96llQB Ty+t1TmCwjKX1+NRnYsAZ7yS8HzjTRfljP6KqKI1ii4Qien0UCxCAzQH95LwoFYa unBxlY4xvf0zuJ0wWjFl3gDEwa0FpWmcldzEqDzmqdyHjNPaFoGhuHYDaSMuNtP+ q1PgsnHUdgA= =TzvO -----END PGP SIGNATURE----- From owner-ietf-open-pgp Thu Sep 11 15:12:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA23024 for ietf-open-pgp-bks; Thu, 11 Sep 1997 15:12:51 -0700 (PDT) Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA23019; Thu, 11 Sep 1997 15:12:47 -0700 (PDT) Received: from beauty.cygnus.com (beauty.cygnus.com [205.180.230.103]) by cygnus.com (8.8.7/8.8.7) with ESMTP id PAA22566; Thu, 11 Sep 1997 15:13:21 -0700 (PDT) From: Marla Pereira Received: (marla@localhost) by beauty.cygnus.com (8.6.9/8.6.4) id PAA23422; Thu, 11 Sep 1997 15:13:02 -0700 Date: Thu, 11 Sep 1997 15:13:02 -0700 Message-Id: <199709112213.PAA23422@beauty.cygnus.com> To: I.Brown@cs.ucl.ac.uk, bonattic@ieca.com Subject: Re: The purpose of this mailing list Cc: ietf-open-pgp@imc.org, phoffman@imc.org, rodney@sabletech.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk hi guys - how do you get off this mailing list??? I have sent three requests already to be removed from the list but there is no indication that there is anybody on the other end?!? Please send suggestions! -- marla@cygnus.com From owner-ietf-open-pgp Thu Sep 11 15:35:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA23217 for ietf-open-pgp-bks; Thu, 11 Sep 1997 15:35:09 -0700 (PDT) Received: from hq.vni.net (root@hq.vni.net [205.252.27.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA23212 for ; Thu, 11 Sep 1997 15:35:02 -0700 (PDT) Received: from PCSLIP.ieca.com (rock-aa-005.vni.net [206.161.70.205]) by hq.vni.net (8.8.5/8.8.5) with SMTP id SAA17009; Thu, 11 Sep 1997 18:35:54 -0400 (EDT) Message-Id: <199709112235.SAA17009@hq.vni.net> Comments: Authenticated sender is From: "Bonatti Chris" Organization: IECA, Inc. To: Marla Pereira Date: Thu, 11 Sep 1997 18:35:51 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: The purpose of this mailing list Reply-to: bonattic@ieca.com CC: ietf-open-pgp@imc.org In-reply-to: <199709112213.PAA23422@beauty.cygnus.com> X-mailer: Pegasus Mail for Win32 (v2.53/R1) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > From: Marla Pereira > Date: Thu, 11 Sep 1997 15:13:02 -0700 > To: I.Brown@cs.ucl.ac.uk, bonattic@ieca.com > Subject: Re: The purpose of this mailing list > Cc: ietf-open-pgp@imc.org, phoffman@imc.org, > rodney@sabletech.com > > hi guys - how do you get off this mailing list??? I have sent > three requests already to be removed from the list but there is > no indication that there is anybody on the other end?!? Please > send suggestions! -- marla@cygnus.com Marla, You should send a message to you can send mail to majordomo@imc.org with the following command in the body of the message. unsubscribe ietf-open-pgp marla@cygnus.com That should do the trick. Chris --------------------------------------------------------------- | International Electronic Communication Analysts, Inc. | | Christopher D. Bonatti 9010 Edgepark Road | | Vice-president Vienna, Virginia 22182 | | bonattic@ieca.com Tel: 301-212-9428 Fax: 703-506-8377 | | PGP public key available from "http://www.ieca.com/" | --------------------------------------------------------------- From owner-ietf-open-pgp Thu Sep 11 15:54:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA23395 for ietf-open-pgp-bks; Thu, 11 Sep 1997 15:54:16 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA23391 for ; Thu, 11 Sep 1997 15:54:12 -0700 (PDT) Received: by brickwall.ceddec.com id <32257>; Thu, 11 Sep 1997 18:54:31 -0400 Date: Thu, 11 Sep 1997 18:55:10 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: Bonatti Chris cc: ietf-open-pgp@imc.org Subject: Re: The purpose of this mailing list In-Reply-To: <199709112133.RAA10330@hq.vni.net> Message-Id: <97Sep11.185431edt.32257@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Thu, 11 Sep 1997, Bonatti Chris wrote: > On Thu, 11 Sep 1997 10:56:06 +0100, Ian Brown wrote: > > > > Here's an ideal opportunity to tie both of these threads > > together. A next generation keyserver could store multiple keys > > for a user, but be able to specify their preferred one. This > > would allow both selection of algorithm and preferred key for > > receiving correspondence, while allowing other keys needed to > > check signatures etc. to be retrieved if necessary. > > This is the best idea yet. It kills 2 bird with one stone. > This approach would suggest a requirement for certificate > structures. > > BTW, I've seen some messages regarding X.509 certificates posted > (both pro and con). I guess my feeling is that whatever we > develop should be flexible enough to work with a variety of > public key management schemes. Large organizations are probably One of my other "stupid PGP tricks" is to convert X.509 to and from PGP (easier now that X509 has DSS, and maybe DH). I can't really convert signatures, but I can move the moduli and other information around. The keyserver protocol is important since I can then integrate the web of trust into SSL, or do the converse, get an X509 certificate to act as a PGP keyring including adding that to the WoT. In some ways, with a few tweaks of the Wot model, the CA hierarchy becomes a subset. So I store a root key or to (mainly for caching) and then calculate validity based on what the keyservers say as to who signed who. From owner-ietf-open-pgp Thu Sep 11 17:48:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA24644 for ietf-open-pgp-bks; Thu, 11 Sep 1997 17:48:49 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA24640 for ; Thu, 11 Sep 1997 17:48:45 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id RAA08637 for ; Thu, 11 Sep 1997 17:50:08 -0700 (PDT) Message-Id: <3.0.2.32.19970911175437.009a7440@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 11 Sep 1997 17:54:37 -0700 To: ietf-open-pgp@imc.org From: Charles Breed Subject: Re: The purpose of this mailing list In-Reply-To: <199709101710.MAA06503@mailhub.amaranth.com> References: <3.0.3.32.19970910084915.00770684@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk As the chief instigator of "Open-PGP", I intended this 'soon-to-be' Working Group to specify the following... 1. PGP Cert (a.k.a. Key) Structure (including X.509 support) 2. PGP as a Public Key (Cert) Infrastruture (we have *lots* of real life experience at MIT, and other places worldwide) 2. MUST algorithms for interoperability 3. correct use of the Trust Models 4. handling MIME 5. limited backwards compatibility with 2.6, 5.x 6. and of course, basic functionality of encrypt, sign, decrypt, verify This might sound like way-too-much for the group to handle, but if we keep to the basics on each topic, and leverage the implementation work that is already done, we can move forward quickly. PGP is already the world's largest PKI, we need to document and make modest enhancements. By having few dependencies on other incomplete specification, Open-PGP will have great benefit by being self contained. (I know I'll be slammed for bring it up, but S/MIME relies on PKCS#1-10, ANSI, CCITT/ITU X.509V3, PKIX, RSASDI and more.) Once the Open-PGP spec is complete, implement to the spec, and compete in an open and fair market. Charles From owner-ietf-open-pgp Thu Sep 11 18:24:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA24969 for ietf-open-pgp-bks; Thu, 11 Sep 1997 18:24:42 -0700 (PDT) Received: from [165.227.249.112] (buddhi.proper.com [165.227.249.112]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA24965 for ; Thu, 11 Sep 1997 18:24:38 -0700 (PDT) Message-Id: In-Reply-To: <3.0.2.32.19970911175437.009a7440@mail.pgp.com> References: <199709101710.MAA06503@mailhub.amaranth.com> <3.0.3.32.19970910084915.00770684@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Sep 1997 18:26:18 -0700 To: ietf-open-pgp@imc.org From: Paul Hoffman / IMC Subject: Re: The purpose of this mailing list Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 5:54 PM -0700 9/11/97, Charles Breed wrote: > 2. PGP as a Public Key (Cert) Infrastruture >(we have *lots* of real life experience at MIT, and other places worldwide) Thanks for clarifying this. My comment earler about the key server lookup protocol not being germain was from not seeing anything like it in the charter. If you as the charter writer think that this was covered, and the rest of the group agrees (as most of the folks have), then it should certainly be part of the work. As folks who have worked in other IETF Working Groups know, things that were "meant" to be in the charter but not stated early in the process usually get forgotten. > 4. handling MIME Jon and I just talked, and we agreed that his earlier statement that this group was not supposed to do the follow-on to PGP/MIME was a misunderstanding. PGP/MIME is the description of handling PGP objects in MIME, and is thus appropriate for the group to discuss. It's certainly one part of what we're doing here. >This might sound like way-too-much for the group to handle... Well, at least you didn't put the PGP API in the list. :-) --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-open-pgp Thu Sep 11 18:56:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA25129 for ietf-open-pgp-bks; Thu, 11 Sep 1997 18:56:24 -0700 (PDT) Received: from aaa.aaa-mainstreet.nl (Ix0oCDlCTadiEaeuxTLHtVy45hrSYkZJ@aaa.aaa-mainstreet.nl [193.67.124.2]) by mail.proper.com (8.8.7/8.7.3) with SMTP id SAA25125 for ; Thu, 11 Sep 1997 18:56:20 -0700 (PDT) From: iang@systemics.com Received: (qmail 22467 invoked by uid 667); 12 Sep 1997 02:03:56 -0000 Date: 12 Sep 1997 02:03:56 -0000 Message-ID: <19970912020356.22466.qmail@aaa.aaa-mainstreet.nl> To: cbreed@pgp.com Subject: Re: The purpose of this mailing list Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Charles, Good list. To which I would add a desperate need: some mechanism in which to add new algorithms. This is partly technical: the formats of some generic public key method are obviously going to be tricky, and the symmetric algorithms require a byte or int allocating type. It's partly managerial: somebody's got to do the work of holding the list of numbers, and allocating new ones. A cryptographic Jon Postel as it where. And it's partly political: someone has got to avoid the various rent-seekers and other squeezers of this world, such that a purely socio-technical benefit is achieved. Maybe this isn't what you intended for the list, but it is something that has dogged the members of the Cryptix Development Team in the past: no way to consistently add a new algorithm. By the end of the year, we will have more than 10 algorithms that we want to put into a new version of PGP code. How? A mystery so far. Whilst on the subject, I'm not sure it is appropriate for PGP, Inc to perform this function. We need someone outside the US. Also PGP, Inc and the predecessor team have a record for secrecy that the NSA would kill for. Not that this is entirely their fault, but history cannot be changed, and it's simply not helpful to the coder. -- iang iang@systemics.com From owner-ietf-open-pgp Thu Sep 11 20:33:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA25999 for ietf-open-pgp-bks; Thu, 11 Sep 1997 20:33:41 -0700 (PDT) Received: from doorstop.cs.auckland.ac.nz (root@doorstop.cs.auckland.ac.nz [130.216.35.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA25995 for ; Thu, 11 Sep 1997 20:33:29 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.33.9]) by doorstop.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id PAA08363; Fri, 12 Sep 1997 15:33:33 +1200 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <87403528719565>; Fri, 12 Sep 1997 15:34:47 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: tzeruch@ceddec.com Subject: Re: The purpose of this mailing list Cc: ietf-open-pgp@imc.org Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Fri, 12 Sep 1997 15:34:47 (NZST) Message-ID: <87403528719565@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >One of my other "stupid PGP tricks" is to convert X.509 to and from PGP >(easier now that X509 has DSS, and maybe DH). I can't really convert >signatures, but I can move the moduli and other information around. I've been working on this too. X.509 -> PGP is doable, but going the other way is pretty challenging since the only thing in a PGP cert is what might be a commonName, and usually an email address, but not a full DN. What thoughts do people have on handling the naming issues? BTW there's an X.509 profile for ElGamal as well as of a week or two ago, check your local internet drafts repository for draft-gutmann-. Peter. From owner-ietf-open-pgp Thu Sep 11 20:54:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA26219 for ietf-open-pgp-bks; Thu, 11 Sep 1997 20:54:56 -0700 (PDT) Received: from [165.227.249.112] (buddhi.proper.com [165.227.249.112]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA26214 for ; Thu, 11 Sep 1997 20:54:51 -0700 (PDT) Message-Id: In-Reply-To: <87403528719565@cs26.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Sep 1997 20:56:34 -0700 To: ietf-open-pgp@imc.org From: Paul Hoffman / IMC Subject: Converting X.509 and PGP certs Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 8:34 AM -0700 9/12/97, Peter Gutmann wrote: >BTW there's an X.509 profile for ElGamal as well as of a week or two ago, >check your local internet drafts repository for draft-gutmann-'elgamal' in it>. Not quite. It's "draft-rfced-info-pgutmann-00.txt", also available from IMC as . Separately, I think any work on full interchange between PGP v3 and v4 certs and X.509 v3certs would be very helpful to the OpenPGP effort. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-open-pgp Thu Sep 11 23:04:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA27095 for ietf-open-pgp-bks; Thu, 11 Sep 1997 23:04:25 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA27087 for ; Thu, 11 Sep 1997 23:04:21 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id XAA11004; Thu, 11 Sep 1997 23:05:31 -0700 (PDT) Message-Id: <3.0.2.32.19970911231000.00ba5a30@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 11 Sep 1997 23:10:00 -0700 To: pgut001@cs.auckland.ac.nz, tzeruch@ceddec.com From: Charles Breed Subject: Re: The purpose of this mailing list Cc: ietf-open-pgp@imc.org In-Reply-To: <87403528719565@cs26.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Well, let's look at the most recent S/MIME draft dated Sept 5th. Cert handling, section 3.1, internet mail address MUST be used as DN, hmmm, sounds like old PGP. I posted some extensions for the naming conventions a while ago, and got some possitive response (besides the ASN.1 encoding example). Open-PGP should use the Pub.Key as Distinguished Name or Principle (as in SDSI), then you can put whatever in the identity / authorization field for binding to the key by a signer. CB At 03:34 PM 9/12/97, Peter Gutmann wrote: >>One of my other "stupid PGP tricks" is to convert X.509 to and from PGP >>(easier now that X509 has DSS, and maybe DH). I can't really convert >>signatures, but I can move the moduli and other information around. > >I've been working on this too. X.509 -> PGP is doable, but going the other >way is pretty challenging since the only thing in a PGP cert is what might be >a commonName, and usually an email address, but not a full DN. What thoughts >do people have on handling the naming issues? > >BTW there's an X.509 profile for ElGamal as well as of a week or two ago, >check your local internet drafts repository for draft-gutmann-'elgamal' in it>. > >Peter. > > > From owner-ietf-open-pgp Thu Sep 11 23:15:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA27211 for ietf-open-pgp-bks; Thu, 11 Sep 1997 23:15:27 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA27207 for ; Thu, 11 Sep 1997 23:15:23 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id XAA11087; Thu, 11 Sep 1997 23:16:45 -0700 (PDT) Message-Id: <3.0.2.32.19970911232114.00ba1e90@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 11 Sep 1997 23:21:14 -0700 To: iang@systemics.com From: Charles Breed Subject: Re: The purpose of this mailing list Cc: ietf-open-pgp@imc.org In-Reply-To: <19970912020356.22466.qmail@aaa.aaa-mainstreet.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Good comments for the list, I suggest a "Capabilities Attribute" that's self-signed and dated to notify the other party of changes (sound familiar?). I could not care less if someone wants to use patented $$$ algorithms, as long as it's NOT a "MUST". OIDs work fine here. PGP 5.x already has this, RSA, DH, DSA, and DES, 3DES, IDEA, CAST, with MD5, SHA-1.... I think we should have DH with DSA, SHA-1 and either 3DES or CAST as a MUST, all else is fair game, but not required. PGP Inc does not want to dictate this list of algorithms, that's what the working group will decide. PS: I'd like to see at least one EC in the list of "MAY" asymmetric algos. CB At 02:03 AM 9/12/97 -0000, iang@systemics.com wrote: >Charles, > >Good list. > >To which I would add a desperate need: some mechanism in which to >add new algorithms. This is partly technical: the formats of some >generic public key method are obviously going to be tricky, and the >symmetric algorithms require a byte or int allocating type. > >It's partly managerial: somebody's got to do the work of holding the >list of numbers, and allocating new ones. A cryptographic Jon Postel >as it where. > >And it's partly political: someone has got to avoid the various >rent-seekers and other squeezers of this world, such that a purely >socio-technical benefit is achieved. > >Maybe this isn't what you intended for the list, but it is something >that has dogged the members of the Cryptix Development Team in the >past: no way to consistently add a new algorithm. By the end of >the year, we will have more than 10 algorithms that we want to put >into a new version of PGP code. How? A mystery so far. > >Whilst on the subject, I'm not sure it is appropriate for PGP, Inc to >perform this function. We need someone outside the US. Also PGP, >Inc and the predecessor team have a record for secrecy that the NSA >would kill for. Not that this is entirely their fault, but history >cannot be changed, and it's simply not helpful to the coder. > >-- >iang >iang@systemics.com > > From owner-ietf-open-pgp Thu Sep 11 23:42:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA27367 for ietf-open-pgp-bks; Thu, 11 Sep 1997 23:42:31 -0700 (PDT) Received: from doorstop.cs.auckland.ac.nz (root@doorstop.cs.auckland.ac.nz [130.216.35.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA27363 for ; Thu, 11 Sep 1997 23:42:24 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.33.9]) by doorstop.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id SAA09958; Fri, 12 Sep 1997 18:42:23 +1200 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <87404661820991>; Fri, 12 Sep 1997 18:43:38 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: cbreed@pgp.com Subject: Re: The purpose of this mailing list Cc: ietf-open-pgp@imc.org Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Fri, 12 Sep 1997 18:43:38 (NZST) Message-ID: <87404661820991@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >PS: I'd like to see at least one EC in the list of "MAY" asymmetric algos. You have to be *very* careful about this, because there are so many variables and parameters involved (field type, representation, field parameters, use of point compression, etc etc) that unless you decide on some useful constraints you'll end up with either specific, optimised implementations which don't interoperate because they use different parameters than everyone else, or incredibly complex and inefficient general-purpose solutions. I think the best approach would be to take P1363 and define an interoperability profile for PGP (MUST use this field type, this curve, point compression, etc etc). A good meet-in-the-middle approach is to take an existing, high-quality PD implementation which anyone can use, an example being George Barwood's pegwit code (there's a link to it somewhere on http://www.cs.auckland.ac.nz/~pgut001/links.html), and defining the parameters to match what the implementation does. This sets a basic level of EC support which is required to interoperate, and simultaneously provides an implementation of the base level which anyone can use. Peter. From owner-ietf-open-pgp Fri Sep 12 04:00:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA01284 for ietf-open-pgp-bks; Fri, 12 Sep 1997 04:00:35 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id EAA01280 for ; Fri, 12 Sep 1997 04:00:28 -0700 (PDT) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 12 Sep 1997 12:01:25 +0100 Message-ID: <34192097.1F5342B@cs.ucl.ac.uk> Date: Fri, 12 Sep 1997 11:59:35 +0100 From: Ian Brown Organization: University College London X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Charles Breed CC: ietf-open-pgp@imc.org Subject: Re: The purpose of this mailing list References: <3.0.3.32.19970910084915.00770684@pop3.pn.com> <3.0.2.32.19970911175437.009a7440@mail.pgp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Ye, spotted some gibberish already... > If I receive a PGP-encrypted message and know > only (say) the key ID, with a distributed system, where do I go to > retrieve the key? Of course, I meant if I receive a PGP-SIGNED message and want to check the signature. Ian. -----BEGIN PGP SIGNATURE----- Version: Cryptix 2.21 iQCVAgUANBkgmppi0bQULdFRAQGkawQAq35kAb6kIZYb7I9UyBDXSPUuquRI4kU4QmbUGnpUc3nD I/XhjgqnmpZ4fBUwb4a8OkibnXLIX8E/1htRdV1VupAUQWFueYTVaVI5ja+Ny2KLplckrHPGijZm Zlz/K7G+YEK+iWQeiX/npnEHdSdnNdjUcFC8uUC0/08W/43VdBE= =phBm -----END PGP SIGNATURE----- From owner-ietf-open-pgp Fri Sep 12 03:58:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA01256 for ietf-open-pgp-bks; Fri, 12 Sep 1997 03:58:11 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id DAA01252 for ; Fri, 12 Sep 1997 03:58:04 -0700 (PDT) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 12 Sep 1997 11:59:07 +0100 Message-ID: <3419200C.F7F6E278@cs.ucl.ac.uk> Date: Fri, 12 Sep 1997 11:57:16 +0100 From: Ian Brown Organization: University College London X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Charles Breed CC: ietf-open-pgp@imc.org Subject: Re: The purpose of this mailing list References: <3.0.3.32.19970910084915.00770684@pop3.pn.com> <3.0.2.32.19970911175437.009a7440@mail.pgp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > As the chief instigator of "Open-PGP", I intended this 'soon-to-be' > Working Group to specify the following... > ... > 2. PGP as a Public Key (Cert) Infrastruture How is the DNSSEC group going on its work to allow public keys to be supplied by the DNS? This would seem a good method of PGP keyserving, as: a) It is totally distributed - there is no way the current system of replicated master keyservers will scale to the millions and millions of users we are aiming for; b) PGP, in effect, uses e-mail addresses as its DNs. Ultimately, as Carl Ellison's SPKI work says, a PGP certificate represents a cyberspace entity, not a physical one. The most we can logically certify on a key, in a large-scale PKI, is that the public key represents a user within a domain who receives e-mail at that address. For example, my public key ID is 'Ian Brown ' - but unless I meet you personally and give you a copy of my fingerprint/full key, there is no way to make a connection between the virtual and physical me. And really, there is little need to. All that is needed - which DNSSEC could provide - is a guarantee by the cs.ucl.ac.uk domain that the public key you possess really does belong to the person who receives mail at I.Brown@cs.ucl.ac.uk. However, it will not be nearly as easy if we use a SDSI solution where the public key IS the DN. If I receive a PGP-encrypted message and know only (say) the key ID, with a distributed system, where do I go to retrieve the key? I think if we are to go the SDSI/SPKI route, we need to embrace it wholeheartedly - so there just will not be a global namespace, and so little need for keyservers. Apologies if this if gibberish, but trying to reconcile DNSSEC, SDSI, SPKI, X.509 and PGP is making my head spin a bit! Ian. -----BEGIN PGP SIGNATURE----- Version: Cryptix 2.21 iQCVAgUANBkgGZpi0bQULdFRAQHOVQP/YVSrUSoJk0wzhj86E4xWjptEKa20uhtLSZ+wlxv7v8LL PPrJwsFgjfhumGqAL7EGTKUKSROGDmUsMgQ5rUWEOTBzvq6cjj4pySFfizvQnfOsYMcVopPoWuuX SHAJjKOUQa6+o46Q/TRz1t2i2C5merJWczNlasxpn++k2nqulJk= =/3eQ -----END PGP SIGNATURE----- From owner-ietf-open-pgp Fri Sep 12 05:55:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA02152 for ietf-open-pgp-bks; Fri, 12 Sep 1997 05:55:54 -0700 (PDT) Received: from hobbes.orl.lmco.com (hobbes.orl.lmco.com [141.240.192.100]) by mail.proper.com (8.8.7/8.7.3) with SMTP id FAA02148 for ; Fri, 12 Sep 1997 05:55:50 -0700 (PDT) Date: Fri, 12 Sep 1997 8:56:02 -0400 (EDT) From: "A. Padgett Peterson P.E. Information Security" To: cbreed@pgp.com CC: ietf-open-pgp@imc.org Message-Id: <970912085602.202052be@hobbes.orl.lmco.com> Subject: Re: The purpose of this mailing list Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Agree & would like to make a comment reguarding key/cert servers as a result of some rumours I am hearing: 1) For the forseeable future, key/cert servers must be able to respond to both "traditional" (PGPv5) requests and x.509 requests 2) This means that the server will need to be able to recognize a x.509 request 2a)This could require a special "x.509 request" 2b)or assume anything that is not "traditional" is x.509 (not a great idea). As a result, for near term I would expect a server to be able to create both types of replies. Further would expect this to be a separate module or wrapper. Since thusfar I have not seen any mention of a "request standard", would like to add this subject. Warmly, Padgett ps PGP so far has skated the issue of Viacrypt and Business Edition (4.0 & last year's 4.5). Am curious what the intention is particularly with respect to platforms *other* than MS W95/NT and Macintosh. From owner-ietf-open-pgp Fri Sep 12 06:06:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA02224 for ietf-open-pgp-bks; Fri, 12 Sep 1997 06:06:26 -0700 (PDT) Received: from hobbes.orl.lmco.com (hobbes.orl.lmco.com [141.240.192.100]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA02220 for ; Fri, 12 Sep 1997 06:06:22 -0700 (PDT) Date: Fri, 12 Sep 1997 9:07:15 -0400 (EDT) From: "A. Padgett Peterson P.E. Information Security" To: ietf-open-pgp@imc.org Message-Id: <970912090715.202052be@hobbes.orl.lmco.com> Subject: While on the subject of standards Sender: owner-ietf-open-pgp@imc.org Precedence: bulk If PGP wishes to succeed in the commercial marketplace, there is another standard that must be considered: FIPS-140. Increasingly I am seeing contracts which have provisions for secure tranmittals which requires this. I would not like to see PGP suceed in becoming an IETF standard but be abandoned for failure to meet. Have not read the whole thing yet but do not see any requirement for key escrow or recovery, most onerous is DES/Triple-DES but that should be something already in consideration as an add-in. Warmly, Padgett From owner-ietf-open-pgp Fri Sep 12 07:27:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA02880 for ietf-open-pgp-bks; Fri, 12 Sep 1997 07:27:19 -0700 (PDT) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA02875 for ; Fri, 12 Sep 1997 07:27:13 -0700 (PDT) Message-Id: <199709121427.HAA02875@mail.proper.com> Received: (qmail 12889 invoked from network); 12 Sep 1997 14:28:27 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 12 Sep 1997 14:28:27 -0000 CC: ietf-open-pgp@imc.org Date: 13 Sep 1997 13:21:39 GMT From: Lindsay Mathieson Mime-Version: 1.0 Subject: Re: While on the subject of standards To: "A. Padgett Peterson P.E. Information Security" X-Mailer: Black Paw Communications's MailCat for Win32 Beta Release Vs 2.6 Content-Type: multipart/mixed;boundary="=====================806638704==_0" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --=====================806638704==_0 Content-Transfer-Encoding: 8bit Content-Type: text/plain;charset=us-ascii >but do not see any requirement for key escrow >or recovery Nor should there be - that is a political issue, and nothing to do with IETF, PGP or non-us parties. -- Lindsay Mathieson Black Paw Communications http://www.blackpaw.com/ --=====================806638704==_0 Content-Transfer-Encoding: 7bit Content-Type: text/x-vcard;charset=us-ascii begin: vcard fn: Lindsay Mathieson n: Lindsay Mathieson;;; email;pref;internet: Lindsay Mathieson org: Black Paw Communications mailer: Black Paw Communications's MailCat for Win32 Beta Release Vs 2.6 end: vcard --=====================806638704==_0-- From owner-ietf-open-pgp Fri Sep 12 08:15:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA03471 for ietf-open-pgp-bks; Fri, 12 Sep 1997 08:15:58 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA03467 for ; Fri, 12 Sep 1997 08:15:53 -0700 (PDT) Received: from crypt.hfinney.com (s13.term1.sb.rain.org [198.68.144.143]) by coyote.rain.org (8.8.5/8.8.5) with ESMTP id IAA08317; Fri, 12 Sep 1997 08:18:02 -0700 (PDT) Received: (from hal@localhost) by crypt.hfinney.com (8.7.4/8.7.3) id HAA11724; Fri, 12 Sep 1997 07:33:22 -0700 Date: Fri, 12 Sep 1997 07:33:22 -0700 From: Hal Finney Message-Id: <199709121433.HAA11724@crypt.hfinney.com> To: ietf-open-pgp@imc.org Subject: Re: The purpose of this mailing list Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 03:34 PM 9/12/97, Peter Gutmann wrote, quoting tzeruch: >>One of my other "stupid PGP tricks" is to convert X.509 to and from PGP >>(easier now that X509 has DSS, and maybe DH). I can't really convert >>signatures, but I can move the moduli and other information around. > >I've been working on this too. X.509 -> PGP is doable, but going the other >way is pretty challenging since the only thing in a PGP cert is what might be >a commonName, and usually an email address, but not a full DN. What thoughts >do people have on handling the naming issues? X.509 V3 does not require distinguished names. You can use alternate names and leave the DN field blank. It should be possible to put the PGP userid in as one of the alternate name forms, probably an email name. So the PGP->X509V3 direction seems simple enough as far as converting just the data in old certs: Some issues remain: - Signature verification is the difficult one. Even if we can structurally reformat the information in PGP certs into an X.509 arrangement, the PGP signatures are not going to validate once the data is reformatted. For importing 509 into PGP, we could specify a new signature type which meant to use 509 formatting for the sig verification. But going from PGP to 509 using legacy PGP certs looks impossible. - People may want to put more information into PGP certs than just email address and common name. For those, the kinds of extensions proposed by Charles Breed seem useful. - People may want to convert 509 certs to PGP and keep the various extension fields and DN tricks which have been used for policies and such. Here is a test 509 cert which one of our employees got from Entrust last year, decoded: Serial number: 840717480 Signature Algorithm: MD5 with RSA encryption (1.2.840.113549.1.1.4) Issuer name: C=Ca (country name) L=Nepean (locality name) OU=No Liability Accepted (organizational unit name) O=For Demo Purposes Only (organizational name) CN=Entrust Demo Web CA (common name) Validity: Not before: Thu Aug 22 13:38:00 1996 +0000 Not after: Fri Nov 22 12:38:00 1996 +0000 Subject name: C=US (country name) ST=Michigan (state or province name) L=Kalamazoo (locality name) O=I/Net, Inc. (organization name) OU=Test PKCS 1024 (organizational unit name) CN=www.inetmi.com (common name) Note the trick of putting liability statements into the issuer DN! 509V3 has a different mechanism for this, but I don't know how widely used it is yet. In order to import this kind of cert into PGP, we could again use the userid extension fields to capture all this cruft. Another alternative is to use the standard RFC1779 encoding of DN's in ASCII, similar to what I used above, and to directly create userids of the form C=Ca, L=Nepean, OU=No Liability Accepted,... Then we might get by with just one new userid type (or even use the existing packets and rely on a parser to recognize when RFC1779 is being used). We wouldn't need multiple new packet types, we'd just use ASCII. Hal Finney hal@pgp.com From owner-ietf-open-pgp Fri Sep 12 08:26:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA03566 for ietf-open-pgp-bks; Fri, 12 Sep 1997 08:26:30 -0700 (PDT) Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA03562 for ; Fri, 12 Sep 1997 08:26:25 -0700 (PDT) Received: from log3 ([128.100.100.195]) by bureau6.utcc.utoronto.ca with SMTP id <160285(8)>; Fri, 12 Sep 1997 11:05:48 -0400 Date: Fri, 12 Sep 1997 11:05:47 -0400 From: robert.guerra@utoronto.ca X-Sender: 01100108@log3 To: Lindsay Mathieson cc: ietf-open-pgp@imc.org Subject: Re: While on the subject of standards In-Reply-To: <199709121427.HAA02875@mail.proper.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Sat, 13 Sep 1997, Lindsay Mathieson wrote: > >but do not see any requirement for key escrow > >or recovery > > Nor should there be - that is a political issue, and nothing to do with IETF, > PGP or non-us parties. > I agree with you totally. There several other places where that discussion should be held...let's not get distracted on the project at hand. regards robert From owner-ietf-open-pgp Fri Sep 12 08:36:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA03675 for ietf-open-pgp-bks; Fri, 12 Sep 1997 08:36:36 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA03670 for ; Fri, 12 Sep 1997 08:36:32 -0700 (PDT) Received: (from hal@localhost) by fusebox.pgp.com (8.8.7/8.8.5) id IAA18013 for ietf-open-pgp@imc.org; Fri, 12 Sep 1997 08:37:58 -0700 (PDT) Date: Fri, 12 Sep 1997 08:37:58 -0700 (PDT) From: Hal Finney Message-Id: <199709121537.IAA18013@fusebox.pgp.com> To: ietf-open-pgp@imc.org Subject: X.509 and PGP (was: The purpose of this mailing list) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk [This is a repost of a message from another account, where the email is getting held or lost. Apologies if you see it again later.] At 03:34 PM 9/12/97, Peter Gutmann wrote, quoting tzeruch: >>One of my other "stupid PGP tricks" is to convert X.509 to and from PGP >>(easier now that X509 has DSS, and maybe DH). I can't really convert >>signatures, but I can move the moduli and other information around. > >I've been working on this too. X.509 -> PGP is doable, but going the other >way is pretty challenging since the only thing in a PGP cert is what might be >a commonName, and usually an email address, but not a full DN. What thoughts >do people have on handling the naming issues? X.509 V3 does not require distinguished names. You can use alternate names and leave the DN field blank. It should be possible to put the PGP userid in as one of the alternate name forms, probably an email name. So the PGP->X509V3 direction seems simple enough as far as converting just the data in old certs. Some issues remain: - Signature verification is the difficult one. Even if we can structurally reformat the information in PGP certs into an X.509 arrangement, the PGP signatures are not going to validate once the data is reformatted. For importing 509 into PGP, we could specify a new signature type which meant to use 509 formatting for the sig verification. But going from PGP to 509 using legacy PGP certs looks impossible. - People may want to put more information into PGP certs than just email address and common name. For those, the kinds of extensions proposed by Charles Breed seem useful. - People may want to convert 509 certs to PGP and keep the various extension fields and DN tricks which have been used for policies and such. Here is a test 509 cert which one of our employees got from Entrust last year, decoded: Serial number: 840717480 Signature Algorithm: MD5 with RSA encryption (1.2.840.113549.1.1.4) Issuer name: C=Ca (country name) L=Nepean (locality name) OU=No Liability Accepted (organizational unit name) O=For Demo Purposes Only (organizational name) CN=Entrust Demo Web CA (common name) Validity: Not before: Thu Aug 22 13:38:00 1996 +0000 Not after: Fri Nov 22 12:38:00 1996 +0000 Subject name: C=US (country name) ST=Michigan (state or province name) L=Kalamazoo (locality name) O=I/Net, Inc. (organization name) OU=Test PKCS 1024 (organizational unit name) CN=www.inetmi.com (common name) Note the trick of putting liability statements into the issuer DN! 509V3 has a different mechanism for this, but I don't know how widely used it is yet. In order to import this kind of cert into PGP, we could again use the userid extension fields to capture all this cruft. Another alternative is to use the standard RFC1779 encoding of DN's in ASCII, similar to what I used above, and to directly create userids of the form C=Ca, L=Nepean, OU=No Liability Accepted,... Then we might get by with just one new userid type (or even use the existing packets and rely on a parser to recognize when RFC1779 is being used). We wouldn't need multiple new packet types, we'd just use ASCII. Hal Finney hal@pgp.com From owner-ietf-open-pgp Fri Sep 12 09:46:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA04595 for ietf-open-pgp-bks; Fri, 12 Sep 1997 09:46:59 -0700 (PDT) Received: from hq.vni.net (root@hq.vni.net [205.252.27.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA04591 for ; Fri, 12 Sep 1997 09:46:55 -0700 (PDT) Received: from PCSLIP.ieca.com (rock-aa-005.vni.net [206.161.70.205]) by hq.vni.net (8.8.5/8.8.5) with SMTP id MAA01103; Fri, 12 Sep 1997 12:48:14 -0400 (EDT) Message-Id: <199709121648.MAA01103@hq.vni.net> Comments: Authenticated sender is From: "Bonatti Chris" Organization: IECA, Inc. To: iang@systemics.com Date: Fri, 12 Sep 1997 12:48:03 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: The purpose of this mailing list Reply-to: bonattic@ieca.com CC: ietf-open-pgp@imc.org In-reply-to: <19970912020356.22466.qmail@aaa.aaa-mainstreet.nl> X-PM-Encryptor: PM-CRYPTPGP, 1 X-mailer: Pegasus Mail for Win32 (v2.53/R1) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On 12 Sep 1997 02:03:56 -0000, iang@systemics.com wrote: > To which I would add a desperate need: some mechanism in which > to add new algorithms. This is partly technical: the formats > of some generic public key method are obviously going to be > tricky, and the symmetric algorithms require a byte or int > allocating type. iang, I think you are correct that this is necessary, but we need to be careful not to start any brush wars. Are there no registries of algorithms for other activities that we can leverage? If so, we should try to use values (OIDs maybe?) already established. Otherwise, a good direction might be to set up a framework for IANA to maintain a registry. This is going to be a common requirement that, I suspect, will span multiple IETF activities. Chris -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAgUBNBkr868wqXqPmmVZAQGVDgQAjzabuKlKghK1pJMeOLLkrtwguIYmbN7m 4Br02bZZnM+koVZp5jUX6klqsv5sFgAeUFILGoOnydwt3/7rRqHWbeer47oUyz04 fMhKL4EAj+vCVDP/tpdmWDoA78nySqCBghb1U9gxI5fKjrNhaQbLyKh6oVp2JESz opP75FvSshU= =7w8k -----END PGP SIGNATURE----- --------------------------------------------------------------- | International Electronic Communication Analysts, Inc. | | Christopher D. Bonatti 9010 Edgepark Road | | Vice-president Vienna, Virginia 22182 | | bonattic@ieca.com Tel: 301-212-9428 Fax: 703-506-8377 | | PGP public key available from "http://www.ieca.com/" | --------------------------------------------------------------- From owner-ietf-open-pgp Fri Sep 12 12:05:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA06501 for ietf-open-pgp-bks; Fri, 12 Sep 1997 12:05:58 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA06497 for ; Fri, 12 Sep 1997 12:05:54 -0700 (PDT) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id MAA21377; Fri, 12 Sep 1997 12:07:09 -0700 (PDT) Message-Id: <3.0.2.32.19970912120039.00b98d90@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 12 Sep 1997 12:00:39 -0700 To: Ian Brown , Charles Breed From: Jon Callas Subject: Re: The purpose of this mailing list Cc: ietf-open-pgp@imc.org In-Reply-To: <3419200C.F7F6E278@cs.ucl.ac.uk> References: <3.0.3.32.19970910084915.00770684@pop3.pn.com> <3.0.2.32.19970911175437.009a7440@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 11:57 AM 9/12/97 +0100, Ian Brown wrote: b) PGP, in effect, uses e-mail addresses as its DNs. Ultimately, as Carl Ellison's SPKI work says, a PGP certificate represents a cyberspace entity, not a physical one. The most we can logically certify on a key, in a large-scale PKI, is that the public key represents a user within a domain who receives e-mail at that address. For example, my public key ID is 'Ian Brown ' - but unless I meet you personally and give you a copy of my fingerprint/full key, there is no way to make a connection between the virtual and physical me. And really, there is little need to. All that is needed - which DNSSEC could provide - is a guarantee by the cs.ucl.ac.uk domain that the public key you possess really does belong to the person who receives mail at I.Brown@cs.ucl.ac.uk. However, it will not be nearly as easy if we use a SDSI solution where the public key IS the DN. If I receive a PGP-encrypted message and know only (say) the key ID, with a distributed system, where do I go to retrieve the key? I think if we are to go the SDSI/SPKI route, we need to embrace it wholeheartedly - so there just will not be a global namespace, and so little need for keyservers. Apologies if this if gibberish, but trying to reconcile DNSSEC, SDSI, SPKI, X.509 and PGP is making my head spin a bit! This isn't gibberish at all. It's closely related to a number of issues we've been dealing with. I agree and disagree with your statement, "P, in effect, uses e-mail addresses as its DNs." I agree in that an Internet Email Address *is* a DN. There are a couple obvious issues that causes people to stress over admitting this (for example, multiple people could use a single email account), but these same issues are there for any other form of DN (let's face it, even if you solve the DN problem, there are corresponding gray areas like the DN for the tech support group of XYZcorp, or the fact that the mail sent to a Famous Person is likely to be read by an aide, in many households there is one partner whose task it is to do the bills and thus will read mail addressed to someone else). Email addresses are DNs, but email addresses are not the sole DN that PGP uses. A PGP cert can have many email addresses attached to it. Yes, I am aware of the apparent contradiction of a cert having many DNs. I'll point you to some of Carl's work on naming, and frankly I don't see a problem with a cert having multiple DNs, but that's me. The way that PGP users identify keys is by key fingerprint. Yeah, it also uses keyid, too, but this is the "real" way that we PGP users verify a key -- we check fingerprint. So you can consider the fingerprint to be a DN. But wait, there's more. If you have two PGP certs that contain the same key material, PGP will merge them. I think this needs to change sooner or later, but that's the way things are presently. So from this aspect, the truest DN is the key itself. The notion that the fingerprint or key itself is the truest DN sounds pretty SPKI/SDSI-like to me. Carl likes to ding PGP for being name-centric, and I hiss at him everytime he does, because I don't think it is. The last time we talked (last week at the W3C meeting in Belgium), I pointed out that in his talk he said that the *only* application of PKC where names are important is email. Well? What is PGP used most for? What are we trying to grow it past? Email. So what's the big deal? The biggest advantage of a PGP cert has is the way that it is "agile" as I've heard some people call it. If you want to look at how you fit PGP into a world that thinks names are important, you can use an email address as a DN. If you want to use PGP in a name where keys are important, use the fingerprint (or key proper) as a DN. No biggie. In fact, one of the central points of the way the web of trust is organized relates directly to resolving this apparent dichotomy. The PGP software, since its earliest days, manages this apparent dichotomy. The beauty of PGP as a PKI is that it can easily bridge an X.509-like, name-centric world to a SPKI-like, key-centric world. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 From owner-ietf-open-pgp Fri Sep 12 14:02:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA07785 for ietf-open-pgp-bks; Fri, 12 Sep 1997 14:02:15 -0700 (PDT) Received: from hermes.ex.ac.uk (hermes.ex.ac.uk [144.173.6.14]) by mail.proper.com (8.8.7/8.7.3) with SMTP id OAA07781 for ; Fri, 12 Sep 1997 14:02:05 -0700 (PDT) Received: from aba@dialup08 [144.173.6.208] by hermes via ESMTP (WAA24036); Fri, 12 Sep 1997 22:02:20 +0100 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id SAA00852; Fri, 12 Sep 1997 18:33:32 +0100 Date: Fri, 12 Sep 1997 18:33:32 +0100 Message-Id: <199709121733.SAA00852@server.test.net> From: Adam Back To: cbreed@pgp.com CC: iang@systemics.com, ietf-open-pgp@imc.org In-reply-to: <3.0.2.32.19970911232114.00ba1e90@mail.pgp.com> (message from Charles Breed on Thu, 11 Sep 1997 23:21:14 -0700) Subject: Elgamal != DH (was Re: The purpose of this mailing list) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Charles Breed writes: > OIDs work fine here. PGP 5.x already has this, RSA, DH, DSA, and DES, 3DES, Could we call ElGamal ElGamal, please? It's not just a nit, what happens when someone wants to put real DH into the spec, are you going to call it "realDH" or "DH2"? Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Fri, 12 Sep 1997 14:27:08 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.33.9]) by doorstop.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id JAA13872; Sat, 13 Sep 1997 09:27:11 +1200 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <87409970622505>; Sat, 13 Sep 1997 09:28:26 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: hal@rain.org, ietf-open-pgp@imc.org Subject: Re: The purpose of this mailing list Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Sat, 13 Sep 1997 09:28:26 (NZST) Message-ID: <87409970622505@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Death rays from Mars made Hal Finney write: >At 03:34 PM 9/12/97, Peter Gutmann wrote, quoting tzeruch: >>>One of my other "stupid PGP tricks" is to convert X.509 to and from PGP >>>(easier now that X509 has DSS, and maybe DH). I can't really convert >>>signatures, but I can move the moduli and other information around. >> >>I've been working on this too. X.509 -> PGP is doable, but going the other >>way is pretty challenging since the only thing in a PGP cert is what might be >>a commonName, and usually an email address, but not a full DN. What thoughts >>do people have on handling the naming issues? >X.509 V3 does not require distinguished names. You can use alternate names >and leave the DN field blank. [For non-X.509 types, what you need to do is leave the DN empty and add an altName attribute containing the email address, which is marked as critical so that the program using the cert has to handle the altName] This is a very risky move, because it makes the resulting cert unusable with X.500/LDAP directories (I have some comments on this usage in my X.509 style guide, http://www.cs.auckland.ac.nz/~pgut001/x509guide.txt). >Here is a test 509 cert which one of our employees got from Entrust last >year, decoded: >[...] >Note the trick of putting liability statements into the issuer DN! Which is very naughty, and another X.500/LDAP-breaking kludge. >Another alternative is to use the standard RFC1779 encoding of DN's in ASCII, >similar to what I used above, and to directly create userids of the form >C=Ca, L=Nepean, OU=No Liability Accepted,... Then we might get by with just >one new userid type (or even use the existing packets and rely on a parser to >recognize when RFC1779 is being used). We wouldn't need multiple new packet >types, we'd just use ASCII. Given the rather broken DirectoryString string formats (again, see the 'guide), you're going to see a lot of Unicode strings in non-English-speaking countries which will mean people have to resort to odd encodings like UTF variants for RFC 1779-compatibility (I'll have to check to see what 1779 says about non-ASCII character sets, but I assume you have to mangle things to get 7-bit characters). Peter. From owner-ietf-open-pgp Fri Sep 12 15:42:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA08963 for ietf-open-pgp-bks; Fri, 12 Sep 1997 15:42:42 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA08959 for ; Fri, 12 Sep 1997 15:42:38 -0700 (PDT) Received: from crypt.hfinney.com (s20.term2.sb.rain.org [198.68.144.180]) by coyote.rain.org (8.8.5/8.8.5) with ESMTP id PAA24788 for ; Fri, 12 Sep 1997 15:44:48 -0700 (PDT) Received: (from hal@localhost) by crypt.hfinney.com (8.7.4/8.7.3) id PAA13126 for ietf-open-pgp@imc.org; Fri, 12 Sep 1997 15:09:50 -0700 Date: Fri, 12 Sep 1997 15:09:50 -0700 From: Hal Finney Message-Id: <199709122209.PAA13126@crypt.hfinney.com> To: ietf-open-pgp@imc.org Subject: Re: Elgamal != DH (was Re: The purpose of this mailing list) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back writes: > Could we call ElGamal ElGamal, please? > > It's not just a nit, what happens when someone wants to put real DH > into the spec, are you going to call it "realDH" or "DH2"? Actually the algorithm identifiers in the 5.0 source are: PGP_PKALG_RSA PGP_PKALG_ELGAMAL PGP_PKALG_DSA It has always been called ElGamal in the source. In the past, Adam and I have discussed the question of how proper it is to refer to ElGamal as a variant of Diffie-Hellman. This is an issue of terminology and people may differ in their preferred usage. In my opinion, DH strictly refers to a key exchange algorithm which requires messages to flow both ways, and cannot be used for email in that form. There are several ways in which DH can be adapted to the requirement for one-way communication, which have various pros and cons with respect to multiple recipients, shared primes, and other issues. ElGamal is one such method. It is possible in the future that we could support other forms of encryption that fall into the DH "family", but I don't think it would be proper to single any of these out and call it DH to the exclusion of the others. So I don't think we will ever have "Diffie-Hellman" as a public key encryption algorithm. Hal From owner-ietf-open-pgp Sat Sep 13 08:39:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA16334 for ietf-open-pgp-bks; Sat, 13 Sep 1997 08:39:46 -0700 (PDT) Received: from public.uni-hamburg.de (public.uni-hamburg.de [134.100.41.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA16330 for ; Sat, 13 Sep 1997 08:39:41 -0700 (PDT) Received: from max-139.public.uni-hamburg.de by public.uni-hamburg.de (AIX 4.1/UCB 5.64/4.03) id AA17902; Sat, 13 Sep 1997 17:41:07 +0200 Received: by ulf.mali.sub.org (Smail3.1.28.1 #1) id m0x9rfS-0003bFC; Sat, 13 Sep 97 14:51 GMT+0200 Message-Id: Date: Sat, 13 Sep 97 14:51 GMT+0200 From: Bodo_Moeller@public.uni-hamburg.de (Bodo Moeller) To: ietf-open-pgp@imc.org Subject: Re: Elgamal != DH In-Reply-To: <199709122209.PAA13126@crypt.hfinney.com> Organization: =?ISO-8859-1?B?SW5zdGl0dXQgPT9JU08tODg1OS0xP1E/Zj1GQ3JfdmVyc2Nodz1GNnJ1bmdzdGhlb3JldGlzY2hlPz0gSW5mb3JtYXRpaw==?= Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hal Finney : > In the past, Adam and I have discussed the question of how proper it is > to refer to ElGamal as a variant of Diffie-Hellman. This is an issue of > terminology and people may differ in their preferred usage. > In my opinion, DH strictly refers to a key exchange algorithm which > requires messages to flow both ways, In the scheme presented in the Diffie-Hellman journal paper, _all_ the public parameters y_user (= g^x_user MOD p) are stored in a public directory (and everybody uses the same prime and generator). The secret value y_Alice ^ x_Bob = y_Bob ^ x_Alice (mod p), which is known only to Alice and Bob and can be used as a symmetric key, is thus fixed, and no messages at all (not counting access to the public directory) have to flow to compute it. The patent (R.I.P.), which lists Diffie, Hellman and Merkle as inventors, describes the exchange algorithm where all x's and y's are ephemeral. I think the text also mentions the variant where the recipient's parameters are fixed and only the sender creates new values (like in ElGamal-encryption), but this is described as a means to obtain "authentication": The sender can be sure that only the intended recipient, and no "man in the middle", can compute the symmetric key y^x. (This use of the word "authentication" may appear a little strange today, but of course all the literature about public key cryptography, digital signatures etc. did not yet exist then, so Diffie et al. can't be blamed.) ElGamal added the idea to use the symmetric key k = y^x MOD p directly for Vernam encryption. (Vernam encryption can be done in any finite group, not just in ({0,1}^n, XOR). ElGamal's paper proposes the groups ((Z/pZ)*, *) and (Z/pZ, +).) Collecting all those names, ElGamal's encryption algorithm could be called the Diffie-Hellman-Merkle-Vernam-ElGamal algorithm. If that appears too long, "ElGamal encryption" is probably most appropriate. This naming, however, leads to a new risk: It might suggest that ElGamal _encryption_ and the ElGamal _signature_ scheme are basically the same thing (like RSA encryption and RSA signatures are), while in fact they are two different algorithms. E.g., PGP Inc.'s "Cryptography Reference Chart" (August 1997) claims that the ElGamal scheme can be "used both for digital signatures and encryption". But that's not true: ElGamal published _two_ schemes (both of which use Diffie-Hellman parameters): one for encryption (the "Diffie-Hellman-Merkle-Vernam-ElGamal" algorithm), and one for signatures; the latter being the major contribution of his paper. Bodo Moeller From owner-ietf-open-pgp Sat Sep 13 09:35:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA16692 for ietf-open-pgp-bks; Sat, 13 Sep 1997 09:35:36 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA16688 for ; Sat, 13 Sep 1997 09:35:32 -0700 (PDT) Received: by brickwall.ceddec.com id <32257>; Sat, 13 Sep 1997 12:36:02 -0400 Date: Sat, 13 Sep 1997 12:36:34 -0400 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars.ceddec.com To: Hal Finney cc: ietf-open-pgp@imc.org Subject: Re: X.509 and PGP (was: The purpose of this mailing list) In-Reply-To: <199709121537.IAA18013@fusebox.pgp.com> Message-Id: <97Sep13.123602edt.32257@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 12 Sep 1997, Hal Finney wrote: > X.509 V3 does not require distinguished names. You can use alternate > names and leave the DN field blank. It should be possible to put the > PGP userid in as one of the alternate name forms, probably an email name. > So the PGP->X509V3 direction seems simple enough as far as converting just > the data in old certs. > > Some issues remain: > > - Signature verification is the difficult one. Even if we can structurally > reformat the information in PGP certs into an X.509 arrangement, the PGP > signatures are not going to validate once the data is reformatted. For > importing 509 into PGP, we could specify a new signature type which meant > to use 509 formatting for the sig verification. But going from PGP to > 509 using legacy PGP certs looks impossible. My thought is more to find places where X509 calls are made and fake an X509 library that uses the PGP WoT model. Integrating with everything else in fully standard format woudl be difficult, but at the point where there is a callback when there is a failure (when something says it doesn't recognize the authority that signed the cert), install a second mechanism. > - People may want to put more information into PGP certs than just email > address and common name. For those, the kinds of extensions proposed > by Charles Breed seem useful. > > - People may want to convert 509 certs to PGP and keep the various extension > fields and DN tricks which have been used for policies and such. Here is > a test 509 cert which one of our employees got from Entrust last year, > decoded: I used the SSLeay certificate oneline as the "userid" string when going to PGP, and do some parsing for the common name and email going the other way. Quick and dirty, but PGP seems good at extracting the data. From owner-ietf-open-pgp Sat Sep 13 09:44:52 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA16718 for ietf-open-pgp-bks; Sat, 13 Sep 1997 09:44:52 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA16714 for ; Sat, 13 Sep 1997 09:44:49 -0700 (PDT) Received: by brickwall.ceddec.com id <32258>; Sat, 13 Sep 1997 12:45:35 -0400 Date: Sat, 13 Sep 1997 12:46:00 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: The purpose of this mailing list In-Reply-To: <3.0.2.32.19970912120039.00b98d90@mail.pgp.com> Message-Id: <97Sep13.124535edt.32258@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 12 Sep 1997, Jon Callas wrote: > But wait, there's more. If you have two PGP certs that contain the same key > material, PGP will merge them. I think this needs to change sooner or > later, but that's the way things are presently. So from this aspect, the > truest DN is the key itself. The notion that the fingerprint or key itself > is the truest DN sounds pretty SPKI/SDSI-like to me. The key material is now separated into the DSS section and the DH section. What if the DSS is the same and the DH is different - does PGP merge them or not? Which DH material should it use? It may be able to handle multiple userIDs, but what about multiple subkeys? > The biggest advantage of a PGP cert has is the way that it is "agile" as > I've heard some people call it. If you want to look at how you fit PGP into > a world that thinks names are important, you can use an email address as a > DN. If you want to use PGP in a name where keys are important, use the > fingerprint (or key proper) as a DN. No biggie. In fact, one of the central > points of the way the web of trust is organized relates directly to > resolving this apparent dichotomy. The PGP software, since its earliest > days, manages this apparent dichotomy. The beauty of PGP as a PKI is that > it can easily bridge an X.509-like, name-centric world to a SPKI-like, > key-centric world. Exactly - I was trying to get at this point. If I take some of the existing code handling X509 certs and replace that engine with one that uses a PGP superset, maybe stretching the introducers model a little so that CA chains would work like X509 intends, I have one program that can handle both models. If it sees an X509, it just checks the signature chain such that the root CA is adequate to propogate trust. If it sees a PGPish cert, it asks a keyserver or user as necessary. From owner-ietf-open-pgp Mon Sep 15 08:00:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA08845 for ietf-open-pgp-bks; Mon, 15 Sep 1997 08:00:37 -0700 (PDT) Received: from guardian.guard.ncsc.mil (guardian.guard.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA08840 for ; Mon, 15 Sep 1997 08:00:33 -0700 (PDT) Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id LAA09541 for ; Mon, 15 Sep 1997 11:01:46 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma009536; Mon Sep 15 11:01:36 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id KAA00956 for ; Mon, 15 Sep 1997 10:58:39 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id LAA14171; Mon, 15 Sep 1997 11:00:32 -0400 Date: Mon, 15 Sep 1997 11:00:32 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199709151500.LAA14171@argon.ncsc.mil> To: ietf-open-pgp@imc.org Subject: Re: The purpose of this mailing list X-Sun-Charset: US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > From: "A. Padgett Peterson P.E. Information Security" > 1) For the forseeable future, key/cert servers must be able to respond to both > "traditional" (PGPv5) requests and x.509 requests > 2) This means that the server will need to be able to recognize a x.509 request > 2a)This could require a special "x.509 request" > 2b)or assume anything that is not "traditional" is x.509 (not a great idea). > > As a result, for near term I would expect a server to be able to create both > types of replies. Further would expect this to be a separate module or wrapper. > > Since thusfar I have not seen any mention of a "request standard", would like > to add this subject. > Warmly, > Padgett The certificate retrieval protocols for X.509 are being hashed out in the PKIX and ASID working groups, and LDAP certificate servers are being rapidly rolled out by the big web server vendors and the big PC LAN vendors. Perhaps it would be cleaner for a keyserver machine to run a separate PGP keyserver and LDAP X.509 certificate server, instead of trying to merge both into a single executable and/or a single protocol specification. If open-PGP will support X.509 as a means of appealing to commercial installations, open-PGP clients will have be able to talk to the directories in use at those installations. A PGP-specific X.509 certificate retrieval protocol is likely to be a non-starter in corporate environments, and developing one is probably not a good use of this working group's time. From owner-ietf-open-pgp Mon Sep 15 08:56:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA09718 for ietf-open-pgp-bks; Mon, 15 Sep 1997 08:56:28 -0700 (PDT) Received: from rover.cygnus.com (rover.cygnus.com [192.80.44.65]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA09714 for ; Mon, 15 Sep 1997 08:56:24 -0700 (PDT) Received: (from marc@localhost) by rover.cygnus.com (8.8.5/8.6.12) id LAA15072; Mon, 15 Sep 1997 11:56:35 -0400 (EDT) To: Jon Callas Cc: Ian Brown , Charles Breed , ietf-open-pgp@imc.org Subject: Re: The purpose of this mailing list References: <3.0.3.32.19970910084915.00770684@pop3.pn.com> <3.0.2.32.19970911175437.009a7440@mail.pgp.com> <3.0.2.32.19970912120039.00b98d90@mail.pgp.com> From: Marc Horowitz Date: 15 Sep 1997 11:56:35 -0400 In-Reply-To: Jon Callas's message of Fri, 12 Sep 1997 12:00:39 -0700 Message-ID: Lines: 32 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas writes: >> The biggest advantage of a PGP cert has is the way that it is "agile" as >> I've heard some people call it. If you want to look at how you fit PGP into >> a world that thinks names are important, you can use an email address as a >> DN. If you want to use PGP in a name where keys are important, use the >> fingerprint (or key proper) as a DN. No biggie. In fact, one of the central >> points of the way the web of trust is organized relates directly to >> resolving this apparent dichotomy. The PGP software, since its earliest >> days, manages this apparent dichotomy. The beauty of PGP as a PKI is that >> it can easily bridge an X.509-like, name-centric world to a SPKI-like, >> key-centric world. I see one problem with this approach, and that is in looking up keys. If we use the email address as the DN, then DNS will make an excellent mechanism for looking up keys. Of course, email addresses have certain problems as DN's, as Carl will point out of I don't. If we think of the key as the DN, then we avoid those problems, but create a different one: given a signature, how do I find the key to use to verify it? Past solutions are to carry certs around within every message, which is inefficient, or to have a global index, which doesn't scale. We need to solve this problem. One option which comes to mind is to include a "domain name" for the a pgp cert RR with the message instead of the cert itself; this does not need to be signed, as the message verification will fail if it is modified. Unfortunately, this has the problem that cert domain names may change or go away, making verification in the future difficult unless a long-term cert cache is kept near the message. Marc From owner-ietf-open-pgp Mon Sep 15 09:55:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA10644 for ietf-open-pgp-bks; Mon, 15 Sep 1997 09:55:47 -0700 (PDT) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA10639 for ; Mon, 15 Sep 1997 09:55:43 -0700 (PDT) Received: from users.invweb.net (ppp32.dotstar.net [208.143.93.51]) by users.invweb.net (8.8.7/8.8.7) with SMTP id MAA06565; Mon, 15 Sep 1997 12:56:40 -0400 Message-Id: <199709151656.MAA06565@users.invweb.net> From: "William H. Geiger III" Date: Mon, 15 Sep 97 11:50:24 -0400 Subject: Re: The purpose of this mailing list X-AutoCrypt: This Message AutoEncrypted With E-Secure v1.1b1 X-Distribution: marc@cygnus.com,jon@pgp.com,I.Brown@cs.ucl.ac.uk,cbreed@pgp.com,ietf-open-pgp@imc.org X-WARNING: No PGP Keys Available for the following addresses X-WARNING: I.Brown@cs.ucl.ac.uk,ietf-open-pgp@imc.org X-WARNING: Remove the X-Encrypt YES line from the header to send in the clear X-WARNING: Multiple PGP Keys for the following addresses X-WARNING: cbreed@pgp.com X-WARNING: Set-Up an entry in the *.dft file or remove multiple keys from the keyring X-WARNING: Remove the X-Encrypt YES line from the header to send in the clear To: I.Brown@cs.ucl.ac.uk, cbreed@pgp.com, ietf-open-pgp@imc.org X-PGPAUTOENCRYPT: YES X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.32 b33 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In , on 09/15/97 at 11:56 AM, Marc Horowitz said: >Jon Callas writes: >>> The biggest advantage of a PGP cert has is the way that it is "agile" as >>> I've heard some people call it. If you want to look at how you fit PGP into >>> a world that thinks names are important, you can use an email address as a >>> DN. If you want to use PGP in a name where keys are important, use the >>> fingerprint (or key proper) as a DN. No biggie. In fact, one of the central >>> points of the way the web of trust is organized relates directly to >>> resolving this apparent dichotomy. The PGP software, since its earliest >>> days, manages this apparent dichotomy. The beauty of PGP as a PKI is that >>> it can easily bridge an X.509-like, name-centric world to a SPKI-like, >>> key-centric world. >I see one problem with this approach, and that is in looking up keys. If >we use the email address as the DN, then DNS will make an excellent >mechanism for looking up keys. Of course, email addresses have certain >problems as DN's, as Carl will point out of I don't. If we think of the >key as the DN, then we avoid those problems, but create a different one: >given a signature, how do I find the key to use to verify it? Past >solutions are to carry certs around within every message, which is >inefficient, or to have a global index, which doesn't scale. >We need to solve this problem. One option which comes to mind is to >include a "domain name" for the a pgp cert RR with the message instead of >the cert itself; this does not need to be signed, as the message >verification will fail if it is modified. Unfortunately, this has the >problem that cert domain names may change or go away, making verification >in the future difficult unless a long-term cert cache is kept near the >message. I see some serious problems with using the DNS for key lookups & distribution. - -- What do we do with keys than do not have a "domain"? - -- What do we do with sites that do not wish to manage PGP keys? (currently the PKI is being done on a volentary basis). - -- How do we solve the problem of redundance? ie where are the backups? - -- How do we handle keys that cover multiple domains? - -- What do we do about domains where PGP is illegal?? (Russia, France, China, Cuba, ...) - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNB1bEo9Co1n+aLhhAQGv+gP8CsEVDjHJ/4g40xaRhJqbj0Gfq8CONR9B czQW5UlrSy9cEZb7ltJxtzH6Sjg/QdPnktw52VBWPNvn3PsvL6+BYUUIgq5D0GRm TWxYmALUXyymGmtWvprdNwunXgF2mOlVsXMavwOxVv50LbwVCMW5DrzPJ9hsvLFM C/sXusZytlY= =OsFt -----END PGP SIGNATURE----- From owner-ietf-open-pgp Mon Sep 15 10:45:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA11422 for ietf-open-pgp-bks; Mon, 15 Sep 1997 10:45:34 -0700 (PDT) Received: from rover.cygnus.com (rover.cygnus.com [192.80.44.65]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA11418 for ; Mon, 15 Sep 1997 10:45:29 -0700 (PDT) Received: (from marc@localhost) by rover.cygnus.com (8.8.5/8.6.12) id NAA15197; Mon, 15 Sep 1997 13:46:11 -0400 (EDT) To: "William H. Geiger III" Cc: I.Brown@cs.ucl.ac.uk, cbreed@pgp.com, ietf-open-pgp@imc.org Subject: Re: The purpose of this mailing list References: <199709151656.MAA06565@users.invweb.net> From: Marc Horowitz Date: 15 Sep 1997 13:46:10 -0400 In-Reply-To: "William H. Geiger III"'s message of Mon, 15 Sep 97 11:50:24 -0400 Message-ID: Lines: 57 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk "William H. Geiger III" writes: >> I see some serious problems with using the DNS for key lookups & >> distribution. >> >> - -- What do we do with keys than do not have a "domain"? Manage them some other way, or not at all. Once of the nice things about PGP is that you don't need to follow the rules. However, one thing the IETF has learned is that to have global interoperability, you need to have some ground rules, usually known in the IETF as a "mandatory-to-implement" protocol/transform/whatever. Implementations are free to do other things as well, and domainless keys seem to fall in that category. Blacknet can get their key out by periodic posts to cypherpunks, or whatever. >> - -- What do we do with sites that do not wish to manage PGP keys? >> (currently the PKI is being done on a volentary basis). What did we do with sites that did not wish to manage DNS servers? As clients began to use DNS and administrators stopped mainaining HOSTS.TXT, such sites evolved or perished. We certainly need a transition period, where users with uncooperative domain admins can still publish their keys. Whatever is proposed (DNS, LDAP, or something else), if it is distributed (as it must be, to scale), getting sites to use it will require time and education. >> - -- How do we solve the problem of redundance? ie where are the backups? How do we solve the problem of redundance with DNS? ie where are the backups? DNS inherently supports secondary servers. >> - -- How do we handle keys that cover multiple domains? How do we handle hosts named in multiple domains? CNAMEs are the obvious answer, or you store the key in both domains (similar to having multiple A records). >> - -- What do we do about domains where PGP is illegal?? (Russia, France, >> China, Cuba, ...) The IETF does not concern itself with local politics. IPsec is mandatory for IPv6, and DES is mandatory for IPsec. DES is illegal in those countries, too, but IPsec and IPv6 are progressing on the standards track with DES as a mandatory transform regardless. Governments which insist on maintaining such policies can evolve or perish :-) All that said, I'm not conviced DNS is the right infrastructure. But you'll need to come up with some better objections. Marc From owner-ietf-open-pgp Tue Sep 16 09:49:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA27895 for ietf-open-pgp-bks; Tue, 16 Sep 1997 09:49:07 -0700 (PDT) Received: from merit.edu (merit.edu [198.108.1.42]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA27891 for ; Tue, 16 Sep 1997 09:49:02 -0700 (PDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm054-29.dialip.mich.net [141.211.6.167]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA26228 for ; Tue, 16 Sep 1997 12:50:41 -0400 (EDT) Date: Tue, 16 Sep 97 16:35:38 GMT From: "William Allen Simpson" Message-ID: <6569.wsimpson@greendragon.com> To: ietf-open-pgp@imc.org Subject: Principles and Principals Sender: owner-ietf-open-pgp@imc.org Precedence: bulk What PGP currently does is more akin to SPKI Principals than X.509 Distinguished Names. The PGP public-key is the principal. The principal is used to "distinguish" all manipulations, such as signing and database maintenance. A "hash" of the principal (really just the lower bits) can also be used for database lookup. The PGP principal signs a "tag" called the username (or just PGP user). This tag is not really used to any degree, except for human recognition and database lookup. The optional email address part of the username tag is akin to the optional SPKI or modifier for finding a principal subject or issuer. All fits rather nicely, actually.... no matter what Ellison says. Forget X.509. No good equivalents in PGP. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ietf-open-pgp Tue Sep 16 10:26:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA28594 for ietf-open-pgp-bks; Tue, 16 Sep 1997 10:26:11 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA28589 for ; Tue, 16 Sep 1997 10:26:06 -0700 (PDT) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id KAA12795; Tue, 16 Sep 1997 10:27:21 -0700 (PDT) Message-Id: <3.0.2.32.19970916102052.00a17ae0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 16 Sep 1997 10:20:52 -0700 To: tzeruch@ceddec.com, Jon Callas From: Jon Callas Subject: Re: The purpose of this mailing list Cc: ietf-open-pgp@imc.org In-Reply-To: <97Sep13.124535edt.32259@brickwall.ceddec.com> References: <3.0.2.32.19970912120039.00b98d90@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 12:46 PM 9/13/97 -0400, tzeruch@ceddec.com wrote: On Fri, 12 Sep 1997, Jon Callas wrote: > But wait, there's more. If you have two PGP certs that contain the same key > material, PGP will merge them. I think this needs to change sooner or > later, but that's the way things are presently. So from this aspect, the > truest DN is the key itself. The notion that the fingerprint or key itself > is the truest DN sounds pretty SPKI/SDSI-like to me. The key material is now separated into the DSS section and the DH section. What if the DSS is the same and the DH is different - does PGP merge them or not? Which DH material should it use? It may be able to handle multiple userIDs, but what about multiple subkeys? It's presently possible to separately expire or replace a subkey. There is no reason that you can't have multiple subkeys, and in fact, I see it as inevitable. The present generation of software doesn't have a lot of support for that, but that's okay. The basic architecture, where a signature key provides a framework in which to use a collection of subkeys is a good one. Exactly - I was trying to get at this point. If I take some of the existing code handling X509 certs and replace that engine with one that uses a PGP superset, maybe stretching the introducers model a little so that CA chains would work like X509 intends, I have one program that can handle both models. If it sees an X509, it just checks the signature chain such that the root CA is adequate to propogate trust. If it sees a PGPish cert, it asks a keyserver or user as necessary. Excellent. Actually, though, you don't ask the server for a validity check. Validity is in the eye of the beholder. You use the user's validity (trust) information for that. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 From owner-ietf-open-pgp Tue Sep 16 10:38:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA28799 for ietf-open-pgp-bks; Tue, 16 Sep 1997 10:38:35 -0700 (PDT) Received: from elektra.ultra.net (elektra.ultra.net [199.232.56.13]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA28795 for ; Tue, 16 Sep 1997 10:38:31 -0700 (PDT) Received: from mcfeeley.indusriver.com (mcfeeley.indusriver.com [209.6.112.7]) by elektra.ultra.net (8.8.5/ult1.06) with SMTP id NAA26678 for ; Tue, 16 Sep 1997 13:40:09 -0400 (EDT) Received: from ferguson.indusriver.com (209.6.112.80) by mcfeeley.indusriver.com (WorldMail 1.3.122) for ietf-open-pgp@imc.org; 16 Sep 1997 13:44:10 -0400 Message-Id: <3.0.3.32.19970916133305.006e0184@204.96.36.2> X-PGP-Key: X-Sender: rodney@204.96.36.2 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 16 Sep 1997 13:33:05 -0400 To: ietf-open-pgp@imc.org From: Rodney Thayer Subject: Principles and Principals Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk In the real world is the email address optional? What do people want? In PGP5 the email address is effectively mandatory, if you want to use the key for Eudora, for example. I'm asking what people THINK it should do not what people think of the PGP5 UI. >Date: Tue, 16 Sep 97 16:35:38 GMT >From: "William Allen Simpson" >To: ietf-open-pgp@imc.org >Subject: Principles and Principals >Sender: owner-ietf-open-pgp@imc.org > >What PGP currently does is more akin to SPKI Principals than X.509 >Distinguished Names. > >The PGP public-key is the principal. The principal is used to >"distinguish" all manipulations, such as signing and database >maintenance. A "hash" of the principal (really just the lower bits) can >also be used for database lookup. > >The PGP principal signs a "tag" called the username (or just PGP user). >This tag is not really used to any degree, except for human recognition >and database lookup. > >The optional email address part of the username tag is akin to the >optional SPKI or modifier for finding a principal >subject or issuer. > >All fits rather nicely, actually.... no matter what Ellison says. > >Forget X.509. No good equivalents in PGP. > >WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 >BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > > From owner-ietf-open-pgp Tue Sep 16 11:36:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA29601 for ietf-open-pgp-bks; Tue, 16 Sep 1997 11:36:27 -0700 (PDT) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA29597 for ; Tue, 16 Sep 1997 11:36:20 -0700 (PDT) Received: from users.invweb.net (ppp6.dotstar.net [208.143.93.25]) by users.invweb.net (8.8.7/8.8.7) with SMTP id OAA10065 for ; Tue, 16 Sep 1997 14:37:57 -0400 Message-Id: <199709161837.OAA10065@users.invweb.net> From: "William H. Geiger III" Date: Tue, 16 Sep 97 13:06:58 -0400 Subject: Re: Principles and Principals X-AutoCrypt: This Message AutoEncrypted With E-Secure v1.1b1 X-Distribution: rodney@sabletech.com,ietf-open-pgp@imc.org X-WARNING: No PGP Keys Available for the following addresses X-WARNING: ietf-open-pgp@imc.org X-WARNING: Remove the X-Encrypt YES line from the header to send in the clear To: ietf-open-pgp@imc.org X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.32 b33 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <3.0.3.32.19970916133305.006e0184@204.96.36.2>, on 09/16/97 at 12:33 PM, Rodney Thayer said: >In the real world is the email address optional? What do people want? >In PGP5 the email address is effectively mandatory, if you want to use >the key for Eudora, for example. >I'm asking what people THINK it should do not what people think of the >PGP5 UI. E-Mail address is most definatly not manditory in the real world. It is not even maditory for an e-mail program. :) I don't know if I have posted to this list about my work/research in PGP integration but I have done quite a bit in this area. In any effective e-mail integration some type of list will be needed where keys are crossreferenced with e-mail addresses. This is not needed for all keys, only a minority of keys used. This list is used to handle the following issues: -- Duplicate keys: This is where one will have multiple keys that contain the same e-mail address in the userID fields. In such a case a default key must be selected for use. -- No keys: This is where no key can be found to match the e-mail address in the To:, CC: or Bcc: fields of the message. Several subtopics need to be addressed here: -- No key: The owner of this e-mail address has no key. This covers persons who are not using PGP and/or mailing list or other group postings where encryption is not practical. -- Address Change: The owner of this e-mail address has a key (or multiple keys) but his current address is not in his userID fields (primary or aka). -- No Encryption: The owner of this e-mail address has a key that matches the e-mail address but for whatever reason the user does not want to encrypt mail to that address.( ie the recipiant has 2 userID's on his key; one is his personal e-mail address and the other is his work e-mail address. Due to company policy he is not allowed encrypted mail at work.) This are some of the most common senarios that I have encountered I am sure there are others you can come up with. Now as far as UserID's outside of e-mail use there are a multitude of uses. Internet E-Mail is only one form of message/data exchange. There are numerious propriatory E-Mail formats out there that do not use standard INet e-mail addresses that still can use PGP to encrypt the messages. I am currently working on an Encrypted IRC private chat channel that uses PGP keys for the session key exchange. SSH is another program that could/should be modified to make use of PGP keys for the session key exchange. If you take a look at the PGP Keyserver you will se quite a few UserID's that show FIDO addresses (Yes folks FIDO is alive and well thankyou ). Nom de plume's are quite popular in conjuntion with anonymous remailers. People still like to have an "identity" even when being "anonymous". As governments world wide step up their efforts to crack down on the use of encryption (and free speech in general) expect to see a dramtic increase of this. Basically anything required the exchange of encrypted data can take advantage of the use of PGP keys with or without the use of e-mail addresses. IMHO they are far from manditory in the UserID field. :) - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNB7FLI9Co1n+aLhhAQEy/gP9FUX/3CAG393PAk24MaXUW+QDlw+LOZmk wY5gui8JtvsLxuWR5gotaNOTqn7iY+NksobjdcZBqnNuaqIMUc4yzjvgsLGHVYkf Bk6631NiHqEkQe7K5VMgR1ts7UusNxoPwYGdjBobFL+qbxzPEzbyPA5gyPirPZXP 8W2jZ1pj6SI= =GjXn -----END PGP SIGNATURE----- From owner-ietf-open-pgp Tue Sep 16 12:17:32 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA00287 for ietf-open-pgp-bks; Tue, 16 Sep 1997 12:17:32 -0700 (PDT) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA00283 for ; Tue, 16 Sep 1997 12:17:27 -0700 (PDT) Received: from users.invweb.net (ppp6.dotstar.net [208.143.93.25]) by users.invweb.net (8.8.7/8.8.7) with SMTP id PAA10993 for ; Tue, 16 Sep 1997 15:19:05 -0400 Message-Id: <199709161919.PAA10993@users.invweb.net> From: "William H. Geiger III" Date: Tue, 16 Sep 97 13:49:27 -0400 Subject: An added E-Mail Issue X-AutoCrypt: This Message AutoEncrypted With E-Secure v1.1b1 X-Distribution: ietf-open-pgp@imc.org,rodney@sabletech.com To: ietf-open-pgp@imc.org X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.32 b33 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hi, I forgot to add an important issue that can be addressed by the e-mail<=>PGP Key lookup list. With PGP 5.0's ability to uses multiple encryption/hash algortihms the need has arose to be able to set the default algortihms to be used by an application for a given e-mail address. This can be accomplished by adding an extra field in the lookup list. Things like: -- Owner of address is using 2.6.x therfore RSA/MD5 signatures should only be used. -- Owner of address is using 5.0 but would prefer that RSA/MD5 be used. -- Owner of address has 5.0 but would prefer that RSA/SHA1 be used. ... and so on and so forth. In the settings either for PGP or the application there should be some type of option of a general default algortihm to use when presented with multiple choices: - Owner of address has both DSS & RSA keys but their preferances are unknown. In such a senario it is up to the user to determine which combination of algorithms should be used (Public key, Session key, Private/Signature key, and Hash). This may vary between the different applications that PGP is being used with for a variety of reasons. - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNB7OxY9Co1n+aLhhAQFe2QQAnJhAkwxUj27YUbrDSpaSWuoLX6T6m/lf 4ND34GQB33OfHutaeM1rYAYoA8J0cfEkJB3kY6izbVdh840kvNgKVkezkzwQdqVD /4cJTtUx4DeVbBM5jDXWw1zo/SJN78Hed59VydnoD9PXTrpxnfPaGutUoVLiL6Ze S3Qwaoamxl4= =RSFs -----END PGP SIGNATURE----- From owner-ietf-open-pgp Tue Sep 16 14:23:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA01820 for ietf-open-pgp-bks; Tue, 16 Sep 1997 14:23:39 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA01815 for ; Tue, 16 Sep 1997 14:23:35 -0700 (PDT) Received: by brickwall.ceddec.com id <32258>; Tue, 16 Sep 1997 17:24:40 -0400 Date: Tue, 16 Sep 1997 17:25:16 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: The purpose of this mailing list In-Reply-To: <3.0.2.32.19970916102052.00a17ae0@mail.pgp.com> Message-Id: <97Sep16.172440edt.32258@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, 16 Sep 1997, Jon Callas wrote: > It's presently possible to separately expire or replace a subkey. There is > no reason that you can't have multiple subkeys, and in fact, I see it as > inevitable. The present generation of software doesn't have a lot of > support for that, but that's okay. The basic architecture, where a > signature key provides a framework in which to use a collection of subkeys > is a good one. Actually it sounds like you are moving toward a model where there are signature capable entities, and encryption capable entities (and things that can do both), so you could mix and match. > Exactly - I was trying to get at this point. If I take some of the > existing code handling X509 certs and replace that engine with one that > uses a PGP superset, maybe stretching the introducers model a little so > that CA chains would work like X509 intends, I have one program that can > handle both models. If it sees an X509, it just checks the signature > chain such that the root CA is adequate to propogate trust. If it sees a > PGPish cert, it asks a keyserver or user as necessary. > > Excellent. Actually, though, you don't ask the server for a validity check. > Validity is in the eye of the beholder. You use the user's validity (trust) > information for that. To clarify, it would access the PGP keyserver so that the key with signatures would be downloaded and any potential revocation! - even most X509 implementations don't really do CRLs yet, so there is that function that would be an immediate improvement. Either it would have enough validity (e.g. I am accessing your web server and I have more than enough signatures of trusted introducers that I accept the key as valid), or it would present to the user a dialog box similar to what netscape does when it doesn't recognize the CA. From owner-ietf-open-pgp Tue Sep 16 14:20:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA01772 for ietf-open-pgp-bks; Tue, 16 Sep 1997 14:20:57 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA01768 for ; Tue, 16 Sep 1997 14:20:53 -0700 (PDT) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id OAA17119; Tue, 16 Sep 1997 14:22:31 -0700 (PDT) Message-Id: <3.0.2.32.19970916141543.009f5c30@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 16 Sep 1997 14:15:43 -0700 To: Rodney Thayer , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Principles and Principals In-Reply-To: <3.0.3.32.19970916133305.006e0184@204.96.36.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 01:33 PM 9/16/97 -0400, Rodney Thayer wrote: In the real world is the email address optional? What do people want? In PGP5 the email address is effectively mandatory, if you want to use the key for Eudora, for example. I'm asking what people THINK it should do not what people think of the PGP5 UI. I want the email address to be optional. I want to be able to have a key that has authorizations only. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 From owner-ietf-open-pgp Tue Sep 16 14:33:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA01945 for ietf-open-pgp-bks; Tue, 16 Sep 1997 14:33:39 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA01941 for ; Tue, 16 Sep 1997 14:33:34 -0700 (PDT) Received: by brickwall.ceddec.com id <32257>; Tue, 16 Sep 1997 17:34:37 -0400 Date: Tue, 16 Sep 1997 17:35:15 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: "William H. Geiger III" cc: ietf-open-pgp@imc.org Subject: Re: An added E-Mail Issue In-Reply-To: <199709161919.PAA10993@users.invweb.net> Message-Id: <97Sep16.173437edt.32257@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, 16 Sep 1997, William H. Geiger III wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > Hi, > > I forgot to add an important issue that can be addressed by the > e-mail<=>PGP Key lookup list. > > With PGP 5.0's ability to uses multiple encryption/hash algortihms the > need has arose to be able to set the default algortihms to be used by an > application for a given e-mail address. This can be accomplished by adding > an extra field in the lookup list. > > Things like: > > -- Owner of address is using 2.6.x therfore RSA/MD5 signatures should > only be used. This is the main thing necessary since it would be theoretically valid to use RSA/MD5 with new PGP 5.0 specific formats (such as the Hash: in the armored files and the new CTB and length format). > -- Owner of address is using 5.0 but would prefer that RSA/MD5 be used. > > -- Owner of address has 5.0 but would prefer that RSA/SHA1 be used. > > ... and so on and so forth. There is already a field in the new signature type packet that indicates the preferred conventional cipher. My notes don't indicate that there is any yet defined for preferred PK cipher, but I think I remember seeing a preferred hash, though it might have been disabled since DSS requires SHA1, and RSA needs MD5 for backward compatibility. A final field would be the preferred signature algorithm, RSA, DSS, or ElGamal if they can get that working securely. --- reply to tzeruch - at - ceddec - dot - com --- From owner-ietf-open-pgp Tue Sep 16 14:54:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA02134 for ietf-open-pgp-bks; Tue, 16 Sep 1997 14:54:19 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA02130 for ; Tue, 16 Sep 1997 14:54:15 -0700 (PDT) Received: by brickwall.ceddec.com id <32257>; Tue, 16 Sep 1997 17:55:25 -0400 Date: Tue, 16 Sep 1997 17:56:03 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: ietf-open-pgp@imc.org Subject: Re: Principles and Principals In-Reply-To: <199709161837.OAA10065@users.invweb.net> Message-Id: <97Sep16.175525edt.32257@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, 16 Sep 1997, William H. Geiger III wrote: > >In the real world is the email address optional? What do people want? > >In PGP5 the email address is effectively mandatory, if you want to use > >the key for Eudora, for example. > > >I'm asking what people THINK it should do not what people think of the > >PGP5 UI. > > E-Mail address is most definatly not manditory in the real world. It is > not even maditory for an e-mail program. :) AGREED! > I don't know if I have posted to this list about my work/research in PGP > integration but I have done quite a bit in this area. As I have. > Now as far as UserID's outside of e-mail use there are a multitude of > uses. Internet E-Mail is only one form of message/data exchange. There are > numerious propriatory E-Mail formats out there that do not use standard > INet e-mail addresses that still can use PGP to encrypt the messages. Some things I can think of: Or to hold a random conventional key for disk or file encryption. A CA style PGP cert - one I just use for signing other keys. Or things simply for signing such as timestamps - I don't need to email back, but I do need to verify the signature of a timestamp. In general, once you have written any key handlers, it is easier to use those style keys than rolling a new certificate format. X509 is an exception because it is very complex and limited. So now that I can generate and pull DSS and DH keys to/from PGP keyrings (I already had RSA style working), I am going to use those same routines, and even some of the conventional stuff is easier to use via my PGPlib API than another rewrite. So there will be many different key types out there. From owner-ietf-open-pgp Tue Sep 16 15:24:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA02526 for ietf-open-pgp-bks; Tue, 16 Sep 1997 15:24:23 -0700 (PDT) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA02520 for ; Tue, 16 Sep 1997 15:24:17 -0700 (PDT) Received: from users.invweb.net (ppp6.dotstar.net [208.143.93.25]) by users.invweb.net (8.8.7/8.8.7) with SMTP id SAA15317 for ; Tue, 16 Sep 1997 18:25:56 -0400 Message-Id: <199709162225.SAA15317@users.invweb.net> From: "William H. Geiger III" Date: Tue, 16 Sep 97 16:53:28 -0400 Subject: Re: An added E-Mail Issue X-AutoCrypt: This Message AutoEncrypted With E-Secure v1.1b1 X-Distribution: tzeruch@ceddec.com,ietf-open-pgp@imc.org To: ietf-open-pgp@imc.org X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.32 b33 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <97Sep16.173437edt.32257@brickwall.ceddec.com>, on 09/16/97 at 04:35 PM, tzeruch@ceddec.com said: >On Tue, 16 Sep 1997, William H. Geiger III wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hi, >> >> I forgot to add an important issue that can be addressed by the >> e-mail<=>PGP Key lookup list. >> >> With PGP 5.0's ability to uses multiple encryption/hash algortihms the >> need has arose to be able to set the default algortihms to be used by an >> application for a given e-mail address. This can be accomplished by adding >> an extra field in the lookup list. >> >> Things like: >> >> -- Owner of address is using 2.6.x therfore RSA/MD5 signatures should >> only be used. >This is the main thing necessary since it would be theoretically valid to >use RSA/MD5 with new PGP 5.0 specific formats (such as the Hash: in the >armored files and the new CTB and length format). >> -- Owner of address is using 5.0 but would prefer that RSA/MD5 be used. >> >> -- Owner of address has 5.0 but would prefer that RSA/SHA1 be used. >> >> ... and so on and so forth. >There is already a field in the new signature type packet that indicates >the preferred conventional cipher. My notes don't indicate that there is >any yet defined for preferred PK cipher, but I think I remember seeing a >preferred hash, though it might have been disabled since DSS requires >SHA1, and RSA needs MD5 for backward compatibility. >A final field would be the preferred signature algorithm, RSA, DSS, or >ElGamal if they can get that working securely. Is there any actual restrictions that DSS *must* use SHA1? It should be able to use any hash that the user selects. It is my understanding that the hash algorithim & the encryption algorithm should be independent of each other (I could be wrong as I have not done an indepth study of that section of code in 5.0). Also a user may wish to use various combinations of Public Key, Session Key, and Hash to be used. I see nothing preventing somone from using RSA Public Key with CAST session key and a SHA1 hash. Now use such a non-standard combination there are two seperate issues that need to be addressed: - -- Myself as a receiver of data. If I wish to receive data in using the above combination I need a mechanism to convay that to the users of my public key. This is best handled with some type of preferance flags in my public key. These settings should only be "preferances" and the sender should have the option to override these (see below). - -- Myself as a sender of data. If I wish to send all my messages out using the above combination I need some method of telling PGP to use this combination if possiable (obviously if I only have a DSS/DH key for the receiver I can't use RSA). This should be both in the form of default settings in the PGP configuration file and on the command line. - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNB76oo9Co1n+aLhhAQG9CAP5ASzbtuukBKAexNfweWGE9K7Tp6lRZcHy SzGGLRfOwBJ+CYzf0S45cGQsM3p42PRJBA6l5jXg/ZyhaXqT7KCriO9+3gNTAG7D z0sRiEjJowhAD7bnY1D6F9w7Q3XcQC9SbIyk44uBNGLGE2oDbEN+ZpA1Us0cO1y8 9YCWRIdUKRk= =CJNm -----END PGP SIGNATURE----- From owner-ietf-open-pgp Tue Sep 16 15:58:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA02881 for ietf-open-pgp-bks; Tue, 16 Sep 1997 15:58:43 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA02877 for ; Tue, 16 Sep 1997 15:58:39 -0700 (PDT) Received: from crypt.hfinney.com (s17.term2.sb.rain.org [198.68.144.177]) by coyote.rain.org (8.8.5/8.8.5) with ESMTP id QAA28776; Tue, 16 Sep 1997 16:01:08 -0700 (PDT) Received: (from hal@localhost) by crypt.hfinney.com (8.7.4/8.7.3) id PAA03925; Tue, 16 Sep 1997 15:48:00 -0700 Date: Tue, 16 Sep 1997 15:48:00 -0700 From: Hal Finney Message-Id: <199709162248.PAA03925@crypt.hfinney.com> To: ietf-open-pgp@imc.org Subject: Re: An added E-Mail Issue Cc: hal@pgp.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Each key determines the public key algorithm to be used to encrypt to it. To send to an RSA key, we use RSA, and to send to an ElGamal key, we use ElGamal, etc. There is also in PGP 5.0 a self-signature packet which allows the key to describe which conventional algorithm(s) it prefers to receive. The issue of choosing a key comes about when multiple keys share a userid, and we are looking up a key on that basis. Then we have the question of which key (or keys) to use to encrypt to that user. If the user has multiple keys which have the same userid, it is not obvious which ones to use. One idea we have discussed at PGP is to combine all the keys belonging to a user into one "key cluster". This would be a generalization of the current structure where we have a signature key with an encryption subkey attached to it. With the key cluster there could be an extra packet which indicated the user's preferences as to which keys to use. This idea works well for email, but perhaps not so well for a capability based model like SPKI. In SPKI, keys have certain attributes or privileges based on the signatures on them. They don't necessarily have userids, and may not be associated with a particular user. There seems less value to clustering keys together in a SPKI-like model. It adds complexity and would make interpreting the attributes of each key more difficult. If we think we will be moving towards a capability system like SPKI, it would be better to avoid doing more with clustering. A possibly simpler way to do handle key preferences would be to allow a key to claim that it has higher priority than a specified list of other keys. So if you had keys A, B, and C matching the desired userid, and A claimed it was higher priority than B, while C claimed to be higher priority than A or B, we would use C. Hal From owner-ietf-open-pgp Tue Sep 16 15:59:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA02905 for ietf-open-pgp-bks; Tue, 16 Sep 1997 15:59:16 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA02900 for ; Tue, 16 Sep 1997 15:59:12 -0700 (PDT) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id QAA18783; Tue, 16 Sep 1997 16:00:50 -0700 (PDT) Message-Id: <3.0.2.32.19970916155403.009b8220@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 16 Sep 1997 15:54:03 -0700 To: "William H. Geiger III" , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: An added E-Mail Issue In-Reply-To: <199709162225.SAA15317@users.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 04:53 PM 9/16/97 -0400, William H. Geiger III wrote: Is there any actual restrictions that DSS *must* use SHA1? It should be able to use any hash that the user selects. It is my understanding that the hash algorithim & the encryption algorithm should be independent of each other (I could be wrong as I have not done an indepth study of that section of code in 5.0). There is kinda sorta a restriction that DSS must use SHA1. DSS is the Digital Signature Standard, and part of that standard is the Secure Hash Algorithm. If you're not using SHA1, then you're not following that standard. So, as far as Layer Nine (the political layer) is concerned, you have to, but the math is a different question. A signature system that uses DSA with RIPEMD160 may be perfectly valid, but it's not DSS. That's why I said "kinda sorta." It's certainly germane to this list to discuss DSS variants, but they're not DSS. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 From owner-ietf-open-pgp Tue Sep 16 16:35:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA03280 for ietf-open-pgp-bks; Tue, 16 Sep 1997 16:35:13 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA03272 for ; Tue, 16 Sep 1997 16:35:07 -0700 (PDT) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id QAA19444; Tue, 16 Sep 1997 16:36:34 -0700 (PDT) Message-Id: <3.0.2.32.19970916162946.009d8100@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 16 Sep 1997 16:29:46 -0700 To: Marc Horowitz , Jon Callas From: Jon Callas Subject: Re: The purpose of this mailing list Cc: Ian Brown , Charles Breed , ietf-open-pgp@imc.org In-Reply-To: References: <3.0.3.32.19970910084915.00770684@pop3.pn.com> <3.0.2.32.19970911175437.009a7440@mail.pgp.com> <3.0.2.32.19970912120039.00b98d90@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 11:56 AM 9/15/97 -0400, Marc Horowitz wrote: Jon Callas writes: I see one problem with this approach, and that is in looking up keys. If we use the email address as the DN, then DNS will make an excellent mechanism for looking up keys. Of course, email addresses have certain problems as DN's, as Carl will point out of I don't. If we think of the key as the DN, then we avoid those problems, but create a different one: given a signature, how do I find the key to use to verify it? Past solutions are to carry certs around within every message, which is inefficient, or to have a global index, which doesn't scale. We need to solve this problem. One option which comes to mind is to include a "domain name" for the a pgp cert RR with the message instead of the cert itself; this does not need to be signed, as the message verification will fail if it is modified. Unfortunately, this has the problem that cert domain names may change or go away, making verification in the future difficult unless a long-term cert cache is kept near the message. Actually, it is good to do both. Here's a quick example: Suppose I want to send a message to my old college roommate, Tom. Unlike Carl Ellison's quandry with his old roommate, Bob, I know precisely which Tom he is. I know his name, address, email address, and phone number. I just don't have his key. Using his email address as a DN with which to look up his key is reasonable. Tom, on the other hand, should be able to use his key with whatever user name (including no user name) he wants, depending on the situation. Once I have his key, I want to see if it's valid. The PGP software will do this for me, and looks up each certification signature of his key using an 8-byte key id. If I phone Tom up to hand-verify it, then we'll use the fingerprint. Each of these is a form of DN, and each has its place. I concur that carrying around certs with messages is a bad solution. Some machanisms for this actually increase the ability for people to do traffic analysis on messages and carry plaintext information in the cert that makes it worse than useless. If my PGP-encrypted mail carried in it my home address and phone number, I think I'd stick to plaintext. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 From owner-ietf-open-pgp Tue Sep 16 20:07:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA05460 for ietf-open-pgp-bks; Tue, 16 Sep 1997 20:07:30 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA05453 for ; Tue, 16 Sep 1997 20:07:25 -0700 (PDT) Received: from crypt.hfinney.com (s24.term1.sb.rain.org [198.68.144.154]) by coyote.rain.org (8.8.5/8.8.5) with ESMTP id UAA13710 for ; Tue, 16 Sep 1997 20:09:55 -0700 (PDT) Received: (from hal@localhost) by crypt.hfinney.com (8.7.4/8.7.3) id RAA04059 for ietf-open-pgp@imc.org; Tue, 16 Sep 1997 17:15:40 -0700 Date: Tue, 16 Sep 1997 17:15:40 -0700 From: Hal Finney Message-Id: <199709170015.RAA04059@crypt.hfinney.com> To: ietf-open-pgp@imc.org Subject: Re: An added E-Mail Issue Sender: owner-ietf-open-pgp@imc.org Precedence: bulk One other clarification: in an encrypted and signed message there are really four algorithms involved: the public-key signature algorithm, the hash algorithm used for the signature, the public-key encryption algorithm, and the conventional cipher algorithm used for encryption. Generally the current PGP implementations assume that the signature and hash algorithm will be chosen by the signer, without regard to the recipient of the message. This is particularly appropriate for messages to large groups and clear-signed messages to public forums, or for messages which may have a long lifetime and be shown to many parties, such as contracts. However for messages to one or a small number of recipients, it might be useful for the sender to know which signature and hash algorithms the recipient prefers or can handle. With encryption, PGP currently chooses the public key and secret key algorithms based on the recipient's preferences. Where we are encrypting to multiple recipients, it chooses a conventional secret key algorithm which all recipients can handle, and aborts if no such algorithm exists. In both cases, it is difficult to know how to balance the interests of the sender of the message and the recipient(s) in terms of choice of algorithms. Each party could have preferences, and possibly vetoes, in terms of what they would like to see used. There may be multiple recipients, and in the case of signatures there may be unknown recipients. We could generalize the preferred-algorithm packets to allow the recipient key to say things like "don't send me messages hashed with MD5" or "only send messages signed with RSA or DSA keys". This could be handled similarly to the current specification of preferred secret algorithms. It is somewhat more awkward to implement because signing is conceptually a distinct step from encryption, and so this requires some internal information flow which would not otherwise be needed. Hal Finney hal@pgp.com From owner-ietf-open-pgp Tue Sep 16 20:07:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA05459 for ietf-open-pgp-bks; Tue, 16 Sep 1997 20:07:29 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA05449 for ; Tue, 16 Sep 1997 20:07:23 -0700 (PDT) Received: from crypt.hfinney.com (s24.term1.sb.rain.org [198.68.144.154]) by coyote.rain.org (8.8.5/8.8.5) with ESMTP id UAA13704 for ; Tue, 16 Sep 1997 20:09:53 -0700 (PDT) Received: (from hal@localhost) by crypt.hfinney.com (8.7.4/8.7.3) id QAA04024 for ietf-open-pgp@imc.org; Tue, 16 Sep 1997 16:56:45 -0700 Date: Tue, 16 Sep 1997 16:56:45 -0700 From: Hal Finney Message-Id: <199709162356.QAA04024@crypt.hfinney.com> To: ietf-open-pgp@imc.org Subject: Re: An added E-Mail Issue Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Regarding SHA with DSA, there is also the issue of hash sizes. DSA, for keys in the range 512-1024 bits (which are the only ones for which it is defined currently) has 160 bits to hold the hash value. SHA-1 produces a 160 bit hash, so that is a good match. DSA is carefully balanced so that the difficulties of breaking the discrete log in either of the two known ways are approximately equal, and also are approximately equal to the difficulty of finding a signature collision. All involve a work factor of about 2^80. If you wanted to use DSA with a hash of < 160 bits, you don't actually get the cryptographic strength which the DSA algorithm is designed to provide. Your hash becomes the weakest link. Other 160 bit hashes than SHA-1, like RIPEMD-160, should be suitable for use with DSA as far as cryptographic strength is concerned. The question of whether to allow non-SHA hashes with DSA is, as Jon says, more political than technical, as long as you keep to consistent sizes. Hal Finney hal@pgp.com From owner-ietf-open-pgp Tue Sep 16 23:36:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA07252 for ietf-open-pgp-bks; Tue, 16 Sep 1997 23:36:38 -0700 (PDT) Received: from netcom10.netcom.com (root@netcom10.netcom.com [192.100.81.120]) by mail.proper.com (8.8.7/8.7.3) with SMTP id XAA07248 for ; Tue, 16 Sep 1997 23:36:35 -0700 (PDT) Received: from [207.94.249.39] (sjc-ca5-21.ix.netcom.com [207.94.249.181]) by netcom10.netcom.com (8.6.13/Netcom) id XAA29450; Tue, 16 Sep 1997 23:38:08 -0700 X-Sender: frantz@netcom10.netcom.com Message-Id: In-Reply-To: <199709162248.PAA03925@crypt.hfinney.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Sep 1997 23:18:06 -0700 To: Hal Finney , ietf-open-pgp@imc.org From: Bill Frantz Subject: Re: An added E-Mail Issue Cc: hal@pgp.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 3:48 PM -0700 9/16/97, Hal Finney wrote: >A possibly simpler way to do handle key preferences would be to allow >a key to claim that it has higher priority than a specified list of >other keys. So if you had keys A, B, and C matching the desired userid, >and A claimed it was higher priority than B, while C claimed to be higher >priority than A or B, we would use C. If B had signed the claim that A was higher priority and A had signed the claim that C was higher priority, then we could even believe the claims. ------------------------------------------------------------------------- Bill Frantz | The Internet was designed | Periwinkle -- Consulting (408)356-8506 | to protect the free world | 16345 Englewood Ave. frantz@netcom.com | from hostile governments. | Los Gatos, CA 95032, USA From owner-ietf-open-pgp Wed Sep 17 05:06:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA12339 for ietf-open-pgp-bks; Wed, 17 Sep 1997 05:06:00 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA12335 for ; Wed, 17 Sep 1997 05:05:56 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id IAA09800; Wed, 17 Sep 1997 08:07:39 -0400 (EDT) Received: by world.std.com (5.65c/Spike-2.0) id AA02168; Wed, 17 Sep 1997 08:07:38 -0400 Message-Id: <199709171207.AA02168@world.std.com> To: Hal Finney Cc: ietf-open-pgp@imc.org Subject: Re: An added E-Mail Issue In-Reply-To: Your message of "Tue, 16 Sep 1997 17:15:40 EDT." <199709170015.RAA04059@crypt.hfinney.com> Date: Wed, 17 Sep 1997 08:07:38 -0400 From: Dan Geer Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > One other clarification: in an encrypted and signed message... I asked an author of the Utah Digital Signature Act last week whether encryption, of and by itself, would constitute the legal force of signature. He said it would. Just a datum... --dan From owner-ietf-open-pgp Wed Sep 17 07:44:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA14194 for ietf-open-pgp-bks; Wed, 17 Sep 1997 07:44:07 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA14079 for ; Wed, 17 Sep 1997 07:39:16 -0700 (PDT) Received: by brickwall.ceddec.com id <32257>; Wed, 17 Sep 1997 10:39:43 -0400 Date: Wed, 17 Sep 1997 10:40:14 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars.ceddec.com To: ietf-open-pgp@imc.org Subject: Re: An added E-Mail Issue In-Reply-To: <3.0.2.32.19970916155403.009b8220@mail.pgp.com> Message-Id: <97Sep17.103943edt.32257@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, 16 Sep 1997, Jon Callas wrote: > Is there any actual restrictions that DSS *must* use SHA1? It should be > able to use any hash that the user selects. It is my understanding that > the hash algorithim & the encryption algorithm should be independent of > each other (I could be wrong as I have not done an indepth study of that > section of code in 5.0). > > There is kinda sorta a restriction that DSS must use SHA1. DSS is the > Digital Signature Standard, and part of that standard is the Secure Hash > Algorithm. If you're not using SHA1, then you're not following that > standard. So, as far as Layer Nine (the political layer) is concerned, you > have to, but the math is a different question. A signature system that uses > DSA with RIPEMD160 may be perfectly valid, but it's not DSS. > > That's why I said "kinda sorta." It's certainly germane to this list to > discuss DSS variants, but they're not DSS. But PGP 5.0 has a test in DSAPubKey.c such that if the hash algorithm is not SHA1, then it doesn't even bother doing the math (around line 172 if I remember - for those with source). It might be better to give a "nonstandard algorithm" warning. From owner-ietf-open-pgp Wed Sep 17 10:10:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA15969 for ietf-open-pgp-bks; Wed, 17 Sep 1997 10:10:29 -0700 (PDT) Received: from guardian.guard.ncsc.mil (guardian.guard.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id KAA15964 for ; Wed, 17 Sep 1997 10:10:25 -0700 (PDT) Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id NAA20162 for ; Wed, 17 Sep 1997 13:11:49 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma020160; Wed Sep 17 13:11:22 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id NAA11093 for ; Wed, 17 Sep 1997 13:08:30 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id NAA18093; Wed, 17 Sep 1997 13:10:22 -0400 Date: Wed, 17 Sep 1997 13:10:22 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199709171710.NAA18093@argon.ncsc.mil> To: ietf-open-pgp@imc.org Subject: Re: Principles and Principals X-Sun-Charset: US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > From: "William Allen Simpson" > > What PGP currently does is more akin to SPKI Principals than X.509 > Distinguished Names. > > The PGP public-key is the principal. The principal is used to > "distinguish" all manipulations, such as signing and database > maintenance. A "hash" of the principal (really just the lower bits) can > also be used for database lookup. > > The PGP principal signs a "tag" called the username (or just PGP user). > This tag is not really used to any degree, except for human recognition > and database lookup. "not really used, except for human recognition and database lookup" ??? Is that like "the car is not really used, except for commuting, vacationing, and taxiing the kids to soccer practice."? SPKI's primary failure (IMO) is it's central design feature: the failure to allow a separation between principals and keyholders. That is, the identity of a principal is inextricably tied to the cryptographic key being used by the principal. I believe it can be accurately claimed that the "PGP user" (the human-readable username) is defined to be the principal, regardless of what cryptographic keys are being used by that principal. "joe@foo.com" is the same person you are accustomed to communicating with, even if he changes his public key. With the SPKI notion of the public key being the principal, the old principal has to delegate to the new one every time keypairs are changed. The inconvenience of managing delegation strongly discourages the use of good key management practices. Those more familiar with PGP operations than I am can judge whether there is a good enough fit between the "cyber-principal to physical-entity" mapping of SPKI vs. the "physical-principal to public key" mapping of PGP and X.509. From owner-ietf-open-pgp Thu Sep 18 09:17:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA03546 for ietf-open-pgp-bks; Thu, 18 Sep 1997 09:17:47 -0700 (PDT) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA03542 for ; Thu, 18 Sep 1997 09:17:43 -0700 (PDT) Received: from users.invweb.net (ppp11.dotstar.net [208.143.93.30]) by users.invweb.net (8.8.7/8.8.7) with SMTP id MAA08888; Thu, 18 Sep 1997 12:18:59 -0400 Message-Id: <199709181618.MAA08888@users.invweb.net> From: "William H. Geiger III" Date: Thu, 18 Sep 97 11:20:33 -0400 To: Dan Geer In-Reply-To: <199709171207.AA02168@world.std.com> Cc: Hal Finney , ietf-open-pgp@imc.org Subject: Re: An added E-Mail Issue X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.32 b33 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <199709171207.AA02168@world.std.com>, on 09/17/97 at 07:07 AM, Dan Geer said: > > One other clarification: in an encrypted and signed message... >I asked an author of the Utah Digital Signature Act >last week whether encryption, of and by itself, would >constitute the legal force of signature. He said it >would. >Just a datum... Hmmmm that seems a little silly to me since anyone can encrypt a message. Encryption alone does not provide authentication. Personally I don't like the way any of these Digital Signature laws have been written. Too many issues involved that have been given little or no consideration by people who do not have a good understanding of the subject. Anyone wishing in discusing this further please e-mail me off list. - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNCFH549Co1n+aLhhAQHS0wP/bJ+Yxsn8XhUHrdX7d6EgZvND824cPd00 FB3HxJX7m8z6o8zmB8Vk8ocMRwJAux5e/Ce42YRDpnbXFe3YABqGwpjeA0JLVebb FmerxfcXYObtyj/oXdfzBBJiJSQnRV80iF80Dyo8mCofz+9m/gChASwIbW6EN+o1 vCurKBxQ/nE= =TVk8 -----END PGP SIGNATURE----- From owner-ietf-open-pgp Thu Sep 18 13:20:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA07461 for ietf-open-pgp-bks; Thu, 18 Sep 1997 13:20:14 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA07455 for ; Thu, 18 Sep 1997 13:20:11 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id NAA23852; Thu, 18 Sep 1997 13:21:54 -0700 (PDT) Message-Id: <3.0.2.32.19970918132624.00be0d80@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 18 Sep 1997 13:26:24 -0700 To: ietf-open-pgp@imc.org From: Charles Breed Subject: Change Control Cc: jis@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just to make things 'crystal clear', let it be known that... "PGP Inc. intends to turn change control of the PGP key and messages formats over to the IETF in a similar way to the way Sun Microsystems turned over RPC in RFC1790." Charles Breed Senior Director fo PGP technologies -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA+AwUBNCGOVIxs4VyrLeD9EQIwVwCYtt9N473qDenEdPLxygWfP+cREwCfbTCH DBuN1nEjYV7DWLmJf+lIUrE= =+Lh0 -----END PGP SIGNATURE----- From owner-ietf-open-pgp Thu Sep 18 13:43:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA07693 for ietf-open-pgp-bks; Thu, 18 Sep 1997 13:43:14 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA07685 for ; Thu, 18 Sep 1997 13:43:07 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id QAA03716; Thu, 18 Sep 1997 16:44:54 -0400 (EDT) Received: by world.std.com (5.65c/Spike-2.0) id AA07307; Thu, 18 Sep 1997 16:44:54 -0400 Message-Id: <199709182044.AA07307@world.std.com> To: "William H. Geiger III" Cc: ietf-open-pgp@imc.org Subject: Re: An added E-Mail Issue In-Reply-To: Your message of "Thu, 18 Sep 1997 11:20:33 EDT." <199709181618.MAA08888@users.invweb.net> Date: Thu, 18 Sep 1997 16:44:53 -0400 From: Dan Geer Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >I asked an author of the Utah Digital Signature Act >last week whether encryption, of and by itself, would >constitute the legal force of signature. He said it >would. Hmmmm that seems a little silly to me since anyone can encrypt a message. Encryption alone does not provide authentication. for clarity, he/I meant that if m is encrypted in your private key then you've acknowledged authorship putting it differently, "signing" is a subset of "encrypting", legally speaking --dan From owner-ietf-open-pgp Thu Sep 18 14:35:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA08307 for ietf-open-pgp-bks; Thu, 18 Sep 1997 14:35:49 -0700 (PDT) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA08303 for ; Thu, 18 Sep 1997 14:35:44 -0700 (PDT) Received: from users.invweb.net (ppp11.dotstar.net [208.143.93.30]) by users.invweb.net (8.8.7/8.8.7) with SMTP id RAA16523; Thu, 18 Sep 1997 17:37:28 -0400 Message-Id: <199709182137.RAA16523@users.invweb.net> From: "William H. Geiger III" Date: Thu, 18 Sep 97 16:34:05 -0400 To: Dan Geer In-Reply-To: <199709182044.AA07307@world.std.com> Cc: "William H. Geiger III" , ietf-open-pgp@imc.org Subject: Re: An added E-Mail Issue X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.32 b33 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <199709182044.AA07307@world.std.com>, on 09/18/97 at 04:44 PM, Dan Geer said: > >I asked an author of the Utah Digital Signature Act > >last week whether encryption, of and by itself, would > >constitute the legal force of signature. He said it > >would. > > Hmmmm that seems a little silly to me since anyone can encrypt a >message. > Encryption alone does not provide authentication. >for clarity, he/I meant that if m is encrypted >in your private key then you've acknowledged >authorship >putting it differently, "signing" is a subset >of "encrypting", legally speaking Nothing personal but I hope the law isn't worded that way. :( In common disscussion of public key encryption when one talks of "Encryption" of a message they are most definatly not speaking of encrypting with ones secret key. I guess one could encrypt the entire message with ones secret key and bypass the use of the hash but it is not a practice I would recomend and it clouds the distinction between standard "encryption" & "signatures" from a legal standpoint. I really feel sorry for the poor shmucks when this stuff winds up in court and they have to explain to a jury that "no they only ment if you encrypted with your secret key ..." - From what I have seen of the various Digital Signature Laws they are a bad thing. - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNCGSjI9Co1n+aLhhAQFgCQP/XFY7Yw/ZJ7Kt80xt9vtp0VvWp2bHmS02 +w8EdKI9nGNFyGEfW4UAZ7lRJo7bfvCJRjQxWuRArM/wg+nr/dTrW+SpjG4dtcz3 kIVG/pGUPrkOcs8U6EaIRAmQwibuws3E1lMqTZNZExDFFwF6T55SbS6yR1/R0ERd 1ZaWQ5l6GFQ= =Yw4m -----END PGP SIGNATURE----- From owner-ietf-open-pgp Thu Sep 18 15:41:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA09015 for ietf-open-pgp-bks; Thu, 18 Sep 1997 15:41:48 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA09010 for ; Thu, 18 Sep 1997 15:41:44 -0700 (PDT) Received: from crypt.hfinney.com (s21.term2.sb.rain.org [198.68.144.181]) by coyote.rain.org (8.8.5/8.8.5) with ESMTP id PAA21422 for ; Thu, 18 Sep 1997 15:44:20 -0700 (PDT) Received: (from hal@localhost) by crypt.hfinney.com (8.7.4/8.7.3) id PAA07179 for ietf-open-pgp@imc.org; Thu, 18 Sep 1997 15:02:37 -0700 Date: Thu, 18 Sep 1997 15:02:37 -0700 From: Hal Finney Message-Id: <199709182202.PAA07179@crypt.hfinney.com> To: ietf-open-pgp@imc.org Subject: Re: An added E-Mail Issue Sender: owner-ietf-open-pgp@imc.org Precedence: bulk William H. Geiger III, , writes: > In common disscussion of public key encryption when one talks of > "Encryption" of a message they are most definatly not speaking of > encrypting with ones secret key. > > I guess one could encrypt the entire message with ones secret key and > bypass the use of the hash but it is not a practice I would recomend and > it clouds the distinction between standard "encryption" & "signatures" > from a legal standpoint. Furthermore, it is not meaningful in general to describe a signature as encryption with the private key. RSA signatures happen to work that way, but discrete log signatures do not. Rather, there is a verification formula which takes the message hash, the public key, and the signature values, and is used to check that the signature is correct. It's very different from either encryption or decryption. Hal Finney hal@pgp.com From owner-ietf-open-pgp Thu Sep 18 16:30:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA09505 for ietf-open-pgp-bks; Thu, 18 Sep 1997 16:30:29 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA09499 for ; Thu, 18 Sep 1997 16:30:25 -0700 (PDT) Received: from [129.46.137.118] (jnoerenberg-mac.qualcomm.com [129.46.137.118]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id QAA05203; Thu, 18 Sep 1997 16:31:08 -0700 (PDT) X-Sender: jwn2@mage.qualcomm.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 4.0a19-9.97] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 18 Sep 1997 16:31:03 -0700 To: ietf-open-pgp@imc.org From: "John W. Noerenberg" Subject: Charter submitted to IESG Cc: "\"Jeffrey I. Schiller\"" , Charles Breed Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Our proposal for a WG is now being considered by the IESG. I expect to hear after the next IESG meeting (9/25) whether we're in business. The charter at the end of the message covers the essential goal of standardizing the way PGP is used for files and for email. I know there are other things we need to tackle (PKI and Cert structure come to mind). But other groups are also working those issues. In order to make sure we get this group up and running, and to make sure we score some early success, I would like to see us focus in on the packet structure, and use in email. No group is currently handling those, so let's see how fast we can get these two done. best, john noerenberg jwn2@qualcomm.com pager: jwn2@pager.qualcomm.com -------------------------------------------------------------------- "We need not to be left alone. We need to be really bothered once in a while." -- Ray Bradbury, Farhenheit 451, 1953 -------------------------------------------------------------------- OpenPGP charter: An Open Specification for Pretty Good Privacy (OpenPGP) Last Modified: 9/18/97 Chair(s): John W Noerenberg Charles Breed Security Area Director(s): Jeffrey Schiller Mailing Lists: General Discussion: ietf-open-pgp@imc.org To Subscribe: ietf-open-pgp-request@imc.org Only the word "subscribe" in the body of the message. Archive: http://www.imc.org/ietf-open-pgp/mail-archive/ Description of the Working Group: PGP, or Pretty Good Privacy, first appeared on the Internet in 1991. It has enjoyed significant popularity amongst the Internet Community. PGP is used both for protecting E-mail and File Storage. It presents a way to digitally sign and encrypt information "objects." As such it is well suited for any store and forward application. The goal of the OpenPGP working group is to provide IETF standards for the algorithms and formats of PGP processed objects as well as providing the MIME framework for exchanging them via e-mail or other transport protocols. Because there is a significant installed base of PGP users, the working group will consider compatibilty issues to avoid disenfranchising the existing community of PGP users. Security Issues: The whole purpose of Open-PGP is to provide security services. Goals and Milestones: October 1997: Submit first internet draft of OPEN-PGP key format and message specification. March 1998: Submit OPEN-PGP key format and message specification for final call. May 1998: Submit OPEN-PGP key format and message specification for Proposed Standard July 1998: WG last call on both drafts for Proposed Standard, (including RFC 2015 or its replacement). -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNCG035WQJPlv1wT4EQKjQgCeIa/vBmoHCS/xmTOe3avxfFAKfTsAmQFu jCxAQg0ToftNNqHc+R2h2gKP =TN97 -----END PGP SIGNATURE----- From owner-ietf-open-pgp Thu Sep 18 17:00:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA09862 for ietf-open-pgp-bks; Thu, 18 Sep 1997 17:00:56 -0700 (PDT) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA09857 for ; Thu, 18 Sep 1997 17:00:52 -0700 (PDT) Received: from users.invweb.net (ppp11.dotstar.net [208.143.93.30]) by users.invweb.net (8.8.7/8.8.7) with SMTP id TAA19724; Thu, 18 Sep 1997 19:49:57 -0400 Message-Id: <199709182349.TAA19724@users.invweb.net> From: "William H. Geiger III" Date: Thu, 18 Sep 97 18:56:08 -0400 To: "John W. Noerenberg" In-Reply-To: Cc: ietf-open-pgp@imc.org, "\"Jeffrey I. Schiller\"" , Charles Breed Subject: Re: Charter submitted to IESG X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.32 b33 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In , on 09/18/97 at 06:31 PM, "John W. Noerenberg" said: >Our proposal for a WG is now being considered by the IESG. I expect to >hear after the next IESG meeting (9/25) whether we're in business. The >charter at the end of the message covers the essential goal of >standardizing the way PGP is used for files and for email. >I know there are other things we need to tackle (PKI and Cert structure >come to mind). But other groups are also working those issues. In order >to make sure we get this group up and running, and to make sure we score >some early success, I would like to see us focus in on the packet >structure, and use in email. No group is currently handling those, so >let's see how fast we can get these two done. what other groups?? - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNCGxmY9Co1n+aLhhAQEJ3AP/WL7qyWipbSAFt1f8DrMyIJHSLhcB5Otb e1nMIL6Xi8mVJ4rHAfLsN/9MUR3nLSnfTklOL+Epfp0FrR1yfEY2Qr3PZ+s33dw4 EvVjAah2pIQbK+Riv+MAhNVOZptOWZuC0o1XJbWI/hHiSYwESsupS3nUvNayoUr9 aC3JXl5BHB4= =DqPd -----END PGP SIGNATURE----- From owner-ietf-open-pgp Thu Sep 18 19:55:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA11405 for ietf-open-pgp-bks; Thu, 18 Sep 1997 19:55:51 -0700 (PDT) Received: from aaa.aaa-mainstreet.nl (6k0Ms9W+TUeukI6k80UsFUYZbnanX8lz@aaa.aaa-mainstreet.nl [193.67.124.2]) by mail.proper.com (8.8.7/8.7.3) with SMTP id TAA11401 for ; Thu, 18 Sep 1997 19:55:47 -0700 (PDT) From: iang@systemics.com Received: (qmail 18256 invoked by uid 667); 19 Sep 1997 03:02:57 -0000 Date: 19 Sep 1997 03:02:57 -0000 Message-ID: <19970919030257.18255.qmail@aaa.aaa-mainstreet.nl> To: ietf-open-pgp@imc.org Subject: Re: Charter submitted to IESG Sender: owner-ietf-open-pgp@imc.org Precedence: bulk John W. Noerenberg wrote: > ...I expect to hear after the next IESG meeting (9/25) whether we're in > business .... for files and for email. > I know there are other things we need to tackle (PKI and Cert structure come > to mind). But other groups are also working those issues. In order to make > sure we get this group up and running, and to make sure we score some early > success, I would like to see us focus in on the packet structure, and use in > email. No group is currently handling those, so let's see how fast we can get > these two done. I hear and concur. Fully, without reservation. People, PGP has taken us this far without a PKI, and without a certificate structure. This is not to say that such potential enhancements are not useful, but rather the beauty of PGP is that it can go *so* far without such. Let us consolidate what we have, in an open framework, in an Internet spirit. I believe that we need to take *existing* work and standardise it such that developers across the Internet and across the world can produce implementations that will deliver the privacy we need. The need to deliver future works is pressing, and for this reason, I would suggest that we need new teams, and new charters, and indeed, new blood, to consider the difficult but necessary tasks of PKI, certificates, and the like. In doing so, I would also represent that such a mission necessarily marches to a different drum, a different timetable. The need for a standard commercial means of determining identity, or of non-repudiation, or of value, is such that it cannot accept the same assumptions as those that make the core of the PGP web of trust. The concepts that make up the architecture of PGP were built on neighbourly trust, not commercial transactions. Door-to-door community, and not commercial advertising. So be it - we have a number of different issues on the table. I think that most PGP hackers would agree that we can build the new requirements on top of the base architecture. I believe this, as I have participated in such projects. However, there is a fundamental difference between standardising and building, between documenting and advancing. The most pressing issue we have is the deployment of a standard in basic packet communications. That is, in deploying a packet format that allows all the various implementations of privacy communications to exchange messages. Our task is only, in the short term, to define and standardise what we can already do. So that implementors can produce the basic framework that allows the future needs to develop. And so that builders have a foundation upon which to build. We need to document and standardise the *current* technology of PGP. As far as I can see, there is only one short term decision. And even this may already be taken, as I was not present at Munich. Is it PGP 2.6 or is it 5.0 ? To my mind it is not important which. I am only here, in this forum, to represent the interests of the Cryptix Development Team in producing a stable crypto architecture based on the lead that has been provided by past hackers. We, of the team, are looking for guidance, we do not offer opinion on the goodness of the architecture, rather, we offer crypto-labour and we wish to labour at this crypto. It is unimportant that 5.0 is "PGP Inc" more than PGP, as long as the former are willing to sign the former over to the latter. What is important is that we have, as a community of Internet crypto coders, a single document that describes the packets we will interchange. Leave the flaws, the optional extras, the extras for later. Let's get the defined PGP out there, and then let's look at building upon a solid, exising definition. > OpenPGP charter: > > An Open Specification for Pretty Good Privacy (OpenPGP) > October 1997: Submit first internet draft of OPEN-PGP key format and > message specification. Today, by the posting of this email, is 0500, 19th of September 1997. Therefore, there are about 2 weeks until October, or say 6 weeks inclusive. We simply must choose one of two bases. We must choose the coding set. And document it. There is no time for anything else. iang From owner-ietf-open-pgp Thu Sep 18 22:25:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA12676 for ietf-open-pgp-bks; Thu, 18 Sep 1997 22:25:24 -0700 (PDT) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id WAA12672 for ; Thu, 18 Sep 1997 22:25:19 -0700 (PDT) Message-Id: <199709190525.WAA12672@mail.proper.com> Received: (qmail 26425 invoked from network); 19 Sep 1997 05:27:05 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 19 Sep 1997 05:27:05 -0000 CC: ietf-open-pgp@imc.org Date: 19 Sep 1997 4:20:48 GMT From: Lindsay Mathieson Subject: Re: Charter submitted to IESG To: iang@systemics.com X-Mailer: Black Paw Communications's MailCat for Win32 Beta Release Vs 2.6.0.1 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >Leave the flaws, the optional extras, the extras for later. Let's >get the >defined PGP out there, and then let's look at building upon a solid, >exising >definition. Hear hear! I've given up on S/MIME - the whole process seems bogged down in a endless series of revisions & discussion on licensing, patents, PKCS XX structures, methods for granting/revoking/reading keys & endless feature discussions. I just looked at the draft OpenPGP spec - its *very* encouraging, as a reasonably compent developer I have no problem with writing my own core implementation. I feel confident that later specifications for PKI etc will be easily integrated. Looking forward to doing so, -- Lindsay Mathieson Black Paw Communications http://www.blackpaw.com/ From owner-ietf-open-pgp Fri Sep 19 04:55:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA17296 for ietf-open-pgp-bks; Fri, 19 Sep 1997 04:55:07 -0700 (PDT) Received: from boeing.rutgers.edu (boeing.rutgers.edu [165.230.8.73]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA17291 for ; Fri, 19 Sep 1997 04:55:03 -0700 (PDT) Received: (from mione@localhost) by boeing.rutgers.edu (8.8.5/8.6.12) id HAA25168; Fri, 19 Sep 1997 07:56:50 -0400 (EDT) From: "Tony Mione" Message-Id: <970919075650.ZM25166@boeing.rutgers.edu> Date: Fri, 19 Sep 1997 07:56:49 -0400 In-Reply-To: "John W. Noerenberg" "Charter submitted to IESG" (Sep 18, 4:31pm) References: X-Mailer: Z-Mail (4.0.1 13Jan97) To: "John W. Noerenberg" , ietf-open-pgp@imc.org Subject: Re: Charter submitted to IESG Cc: "\"Jeffrey I. Schiller\"" , Charles Breed MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Sep 18, 4:31pm, John W. Noerenberg wrote: > Subject: Charter submitted to IESG > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Our proposal for a WG is now being considered by the IESG. I expect to hear > after the next IESG meeting (9/25) whether we're in business. The charter at >... > > best, > > john noerenberg > jwn2@qualcomm.com > pager: jwn2@pager.qualcomm.com > -------------------------------------------------------------------- > "We need not to be left alone. We need to be really > bothered once in a while." > -- Ray Bradbury, Farhenheit 451, 1953 > -------------------------------------------------------------------- > > > OpenPGP charter: > >... > > Goals and Milestones: > > October 1997: Submit first internet draft of OPEN-PGP key format and > message specification. > > March 1998: Submit OPEN-PGP key format and message specification for > final call. > > May 1998: Submit OPEN-PGP key format and message specification for > Proposed Standard > > July 1998: WG last call on both drafts for Proposed Standard, ^^^^ I count only one draft (OPEN-PGP key format and Or does this mean: 1) OPEN-PGP key formats 2) OPEN-PGP message specifications > (including RFC 2015 or its replacement). > ...or 1) OPEN-PGP key format and message specification 2) RFC 2015 and/or replacement If this is the case, should we not have 'review of RFC2015' somewhere in the milestones? >... > >-- End of excerpt from John W. Noerenberg - -- Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650 mione@nbcs-ns.rutgers.edu W3: http://www-ns.rutgers.edu/~mione/ PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F Editorial Advisor for Digital Systems Report ***** Important: John 17:3 ***** -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNCJoXPMKRuSgNA5pAQHTeQMApcsW1V+cMf9mPIX3elJQU5bitLgRovJl MPjlpEReRtSt5EmYKNXA0g1RMTdH8nPtKAdynGvRZzPwjQKGy0QY/yyZh9aCi31e oPHPGeYckPlsiwEd5cnFti0tFBBdnrDo =WpHR -----END PGP SIGNATURE----- From owner-ietf-open-pgp Fri Sep 19 06:45:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA18459 for ietf-open-pgp-bks; Fri, 19 Sep 1997 06:45:36 -0700 (PDT) Received: from drum-damo.army.mil (root@DRUM-DAMO.ARMY.MIL [147.198.110.85]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA18447 for ; Fri, 19 Sep 1997 06:45:31 -0700 (PDT) Received: from greenea.5sigcmd.army.mil ([147.40.40.138]) by drum-damo.army.mil (8.7.5/8.7.3) with SMTP id IAA00922 for ; Fri, 19 Sep 1997 08:51:08 -0400 Received: by greenea.5sigcmd.army.mil from localhost (router,SLmailFW V2.0); Fri, 19 Sep 1997 15:44:22 DST Received: by greenea.5sigcmd.army.mil from greenea.5sigcmd.army.mil (127.0.0.1::mail daemon; unverified,SLmailFW V2.0); Fri, 19 Sep 1997 15:44:21 DST Message-Id: <3.0.3.32.19970919154419.007cd790@[127.0.0.1]> X-Homepage: X-PGP-KeyId: pub 1083 0x78CD4329 X-PGP-Fingerprint: A3 57 37 48 54 88 FE 4A D6 81 C0 74 DA 00 A6 F7 X-Sender: agreene@[127.0.0.1] X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 19 Sep 1997 15:44:19 +0200 To: ietf-open-pgp@imc.org From: "Anthony E. Greene" Subject: Re: An added E-Mail Issue In-Reply-To: <199709182137.RAA16523@users.invweb.net> References: <199709182044.AA07307@world.std.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 16:34 18-09-1997 -0400, you wrote: >>putting it differently, "signing" is a subset >>of "encrypting", legally speaking > >Nothing personal but I hope the law isn't worded that way. :( I'm not sure it's a law yet. The proposal is posted at The wording of the proposal is consistent with accepted practice, and not with the opinion quoted a few days ago on this list. -- Anthony E. Greene From owner-ietf-open-pgp Fri Sep 19 10:52:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA21358 for ietf-open-pgp-bks; Fri, 19 Sep 1997 10:52:29 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA21354 for ; Fri, 19 Sep 1997 10:52:25 -0700 (PDT) Received: from [129.46.137.118] (jnoerenberg-mac.qualcomm.com [129.46.137.118]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id KAA05363; Fri, 19 Sep 1997 10:53:12 -0700 (PDT) X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <970919075650.ZM25166@boeing.rutgers.edu> References: "John W. Noerenberg" "Charter submitted to IESG" (Sep 18, 4:31pm) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 4.0a19-9.97] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Fri, 19 Sep 1997 10:33:40 -0700 To: "Tony Mione" From: "John W. Noerenberg" Subject: Re: Charter submitted to IESG Cc: ietf-open-pgp@imc.org, "\"Jeffrey I. Schiller\"" , Charles Breed Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 7:56 AM -0400 9/19/97, Tony Mione wrote: > >On Sep 18, 4:31pm, John W. Noerenberg wrote: >> Subject: Charter submitted to IESG >> >> >> >> July 1998: WG last call on both drafts for Proposed Standard, > ^^^^ > > I count only one draft (OPEN-PGP key format and Or does this mean: > > 1) OPEN-PGP key formats > 2) OPEN-PGP message specifications > >> (including RFC 2015 or its replacement). >> > > ...or > 1) OPEN-PGP key format and message specification > 2) RFC 2015 and/or replacement > > If this is the case, should we not have 'review of RFC2015' somewhere >in the milestones? Good point, Tony. The IESG has called me to task on it, too. Here the revised milestones I offered for their discussion: >Our milestones outline the progress of two documents to Proposed Standard. > >1) RFC covering PGP Key format and PGP Message format >2) PGP/MIME > >So Steve's on the right track with the milestones, but this is what we're >after: > >Oct 97 Submit Internet-Draft for PGP Key Format & Message Format >Oct 97 Submit revised PGP/MIME RFC > >Mar 98 Issue WG Last Call for both documents > >May 98 Submit PGP Key Format & Message Format Internet-Draft to IESG for >consideration as a Proposed Standard. >May 98 resubmit PGP/MIME Specification to IESG for consideration as a >Proposed Standard > >July 1998: IETF last call for PGP Key Format & PGP Message Specification >July 1998: IETF last call for PGP/MIME (RFC 2015 or its replacement) john noerenberg jwn2@qualcomm.com pager: jwn2@pager.qualcomm.com -------------------------------------------------------------------- "Try designing one set of outfits for the Spice Girls and the Chicago Symphony, and see if anyone is happy." -- Steve Dorner, private email, 1997 -------------------------------------------------------------------- From owner-ietf-open-pgp Tue Sep 23 03:24:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA01504 for ietf-open-pgp-bks; Tue, 23 Sep 1997 03:24:29 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id DAA01500 for ; Tue, 23 Sep 1997 03:24:21 -0700 (PDT) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 Sep 1997 11:26:01 +0100 Message-ID: <342798D4.F0818C87@cs.ucl.ac.uk> Date: Tue, 23 Sep 1997 11:24:20 +0100 From: Ian Brown Organization: University College London X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: William Allen Simpson CC: ietf-open-pgp@imc.org Subject: Re: Principles and Principals References: <6569.wsimpson@greendragon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > The PGP public-key is the principal. The principal is used to > "distinguish" all manipulations, such as signing and database > maintenance. A "hash" of the principal (really just the lower bits) can > also be used for database lookup. > > The PGP principal signs a "tag" called the username (or just PGP user). > This tag is not really used to any degree, except for human recognition > and database lookup. I think this is a great way to look at it. Using the public key, its hash or fingerprint as *the* DN allows all sorts of important functionality like authorisations. E-mail is probably the most widespread use of PGP at the moment, but can be considered separately. E-mail users in effect can state to the world (via keyservers) that their public key 'speaks' for a certain address (to use SPKI lingo). So, if a key is to be used for e-mail, it must contain such a 'tag' with an e-mail address. If not, no problem. With this approach, the distributed keyserver problem becomes simpler. E-mail messages in RFC822 format should contain a From: field; users should simply ensure that the address in this field is included as a 'tag' on their public key. Or you could use a solution like PGP5 and include an X header that specifies exactly how the key can be looked up. Other protocols/message exchange systems can be considered separately. Ian >:) -----BEGIN PGP SIGNATURE----- Version: Cryptix 2.21 iQCVAgUANCeY3ppi0bQULdFRAQF3/QP/RXaQXrtR93KGn0o03hfR7o3kKYQVhUBMOTldFNymtYlZ kDRsCBZEFtc6m1Gxz9p5O8ufqR1m3NqZW9jX24gwlvoogG8fRsEvTJfKV4bJfw1kkKMvjlRECeNX Am22UnM3KxcnkJ3zXjQ8UolVtZfNRvF9IOMDacIYHk1KO07trBo= =765r -----END PGP SIGNATURE----- From owner-ietf-open-pgp Tue Sep 23 23:01:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA12969 for ietf-open-pgp-bks; Tue, 23 Sep 1997 23:01:20 -0700 (PDT) Received: from hq.vni.net (root@hq.vni.net [205.252.27.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA12965 for ; Tue, 23 Sep 1997 23:01:16 -0700 (PDT) Received: from PCSLIP.ieca.com (rock-aa-019.vni.net [206.161.70.219]) by hq.vni.net (8.8.5/8.8.5) with SMTP id CAA23099; Wed, 24 Sep 1997 02:03:18 -0400 (EDT) Message-Id: <199709240603.CAA23099@hq.vni.net> Comments: Authenticated sender is From: "Bonatti Chris" Organization: IECA, Inc. To: Ian Brown Date: Tue, 23 Sep 1997 22:51:28 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Principles and Principals Reply-to: bonattic@ieca.com CC: ietf-open-pgp@imc.org In-reply-to: <342798D4.F0818C87@cs.ucl.ac.uk> X-PM-Encryptor: PM-CRYPTPGP, 1 X-mailer: Pegasus Mail for Win32 (v2.53/R1) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Ian, To take your points out of order: > With this approach, the distributed keyserver problem becomes > simpler. E-mail messages in RFC822 format should contain a > From: field; users should simply ensure that the address in > this field is included as a 'tag' on their public key. Or you > could use a solution like PGP5 and include an X header that > specifies exactly how the key can be looked up. > > Other protocols/message exchange systems can be considered > separately. This is a good approach, although by itself it does not address the totality of the e-mail requirement. You still need some way to bind the e-mail address to the key. Whatever the principal is, this is a function that's got no better place to roost than the public key infrastructure. > I think this is a great way to look at it. Using the public > key, its hash or fingerprint as *the* DN allows all sorts of > important functionality like authorisations. E-mail is probably > the most widespread use of PGP at the moment, but can be > considered separately. E-mail users in effect can state to the > world (via keyservers) that their public key 'speaks' for a > certain address (to use SPKI lingo). So, if a key is to be used > for e-mail, it must contain such a 'tag' with an e-mail > address. If not, no problem. Unless I misunderstand you, the e-mail address is not then bound into the certificate structure. I'm reading out of what your last couple of messages that we would submit the e-mail address as an submission argument to the keyserver, but that this would be absent from the certificate. This is pretty weak in the sense that it is dirt simple for a black-hat to assert a bogus e-mail address (or worse usurp a real one) and provide his own black-hat key ID. This leaves open a lot of possibilities for misuse. I should think that we at least have to have the ability for 3rd party certifications of the public key have the ability to bind over the key ID and e-mail address (or other string). This would in effect be an authorization to use that e-mail address, not a principal. This seems to me a basic characteristic of any public key infrastructure to associate the key with what the key is allowed to do. If I am misrepresenting what you propose, please set me straight. Chris --------------------------------------------------------------- | International Electronic Communication Analysts, Inc. | | Christopher D. Bonatti 9010 Edgepark Road | | Vice-president Vienna, Virginia 22182 | | bonattic@ieca.com Tel: 301-212-9428 Fax: 703-506-8377 | | PGP public key available from "http://www.ieca.com/" | --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAgUBNCg5368wqXqPmmVZAQHpxgQAymRB1d6/o6u8F/c4Pe7QisapaPPx7UGO 1Z61k872Iab75yA8lJ0NKtMhE13oxEMzar+tIf6kwjJ6Q/4GTtsk3OnLwzC0rsUZ qtmP21r3wuUC7vBtwGa5BD+uGtm2s7R9fwuENlquVoKhLhGylRzGoqZZ9a4XtKnh pBVHjUO58eE= =LJG4 -----END PGP SIGNATURE----- From owner-ietf-open-pgp Wed Sep 24 06:48:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA19528 for ietf-open-pgp-bks; Wed, 24 Sep 1997 06:48:53 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA19524 for ; Wed, 24 Sep 1997 06:48:48 -0700 (PDT) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 24 Sep 1997 14:50:41 +0100 Message-ID: <34291A34.19B1C011@cs.ucl.ac.uk> Date: Wed, 24 Sep 1997 14:48:36 +0100 From: Ian Brown Organization: University College London X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: bonattic@ieca.com CC: ietf-open-pgp@imc.org Subject: Re: Principles and Principals References: <199709240603.CAA23099@hq.vni.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > You still need some way > to bind the e-mail address to the key. I think this is where DNSSEC would be enormously useful, by allowing trusted DNS-based lookups of public keys. We can leverage the work done by domains in setting up trust networks to get trusted PGP public keys. > I should think that we at least have to have the ability for > 3rd party certifications of the public key have the ability to > bind over the key ID and e-mail address Of course - it's just that, an Internet-wide WoT could become enormously unwieldy without some form of structure imposed. The DNS is already there, so would be an ideal candidate. > If I am misrepresenting what you propose, please set me > straight. I think I just proposed it in a confused way :-) My main point was that e-mail is an important part, but not the totality, of what we want to do with PGP. I think the keyserver system is something that is very appropriate for e-mail, but in other circumstances such as providing authorisations it would be better for the user to supply the key and associated permissions when (s)he requests the capability ;-) Ian. -----BEGIN PGP SIGNATURE----- Version: Cryptix 2.21 iQCVAgUANCkaO5pi0bQULdFRAQHPVAP/UbtCQIdlehDYDE68JBg5sdX8JYNjlrQTKDMER3RpLJ6z EuDESNMgpTKE4zGug2pILWbYyJAZzEJJYDXZv63PNx+2618sVlqqiSHw7EZdD9s66S6b+cnBAz+O vbzAv6bR2FuKmyuiVWR++NIxTPrLiNiVQGkYmOLCmifQG1smlrc= =cDgy -----END PGP SIGNATURE----- From owner-ietf-open-pgp Wed Sep 24 08:30:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA20722 for ietf-open-pgp-bks; Wed, 24 Sep 1997 08:30:11 -0700 (PDT) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA20718 for ; Wed, 24 Sep 1997 08:30:07 -0700 (PDT) Received: from ppp-hg1-220.ftwotx.onramp.net (ppp-hg1-220.ftwotx.onramp.net [206.50.111.220]) by mailhost.onramp.net (8.8.7/8.8.5) with SMTP id KAA12716; Wed, 24 Sep 1997 10:24:50 -0500 (CDT) Received: by ppp-hg1-220.ftwotx.onramp.net with Microsoft Mail id <01BCC8D3.C4075200@ppp-hg1-220.ftwotx.onramp.net>; Wed, 24 Sep 1997 10:22:31 -0500 Message-ID: <01BCC8D3.C4075200@ppp-hg1-220.ftwotx.onramp.net> From: Rik Drummond To: "'bonattic@ieca.com'" , Ian Brown Cc: "ietf-open-pgp@imc.org" Subject: RE: Principles and Principals Date: Wed, 24 Sep 1997 10:07:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----Original Message----- From: Bonatti Chris [SMTP:bonattic@ieca.com] Sent: Tuesday, September 23, 1997 4:51 PM To: Ian Brown Cc: ietf-open-pgp@imc.org Subject: Re: Principles and Principals -----BEGIN P