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 &