Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA17582 for ietf-open-pgp-bks; Thu, 29 Jan 1998 17:42:21 -0800 (PST) Received: from newmail.virgin.net (newmail.virgin.net [194.168.54.44]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA17578 for ; Thu, 29 Jan 1998 17:42:14 -0800 (PST) Received: from server.eternity.org ([194.168.65.18]) by newmail.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 549-33929U100000L2S50) with ESMTP id AAE15014; Fri, 30 Jan 1998 01:47:13 +0000 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id AAA00660; Fri, 30 Jan 1998 00:53:36 GMT Date: Fri, 30 Jan 1998 00:53:36 GMT Message-Id: <199801300053.AAA00660@server.eternity.org> From: Adam Back To: I.Brown@cs.ucl.ac.uk CC: ryan@michonline.com, ietf-open-pgp@imc.org In-reply-to: <949.885931059@cs.ucl.ac.uk> (message from Ian BROWN on Tue, 27 Jan 1998 19:57:39 +0000) Subject: proposed edit (Re: OpenPGP WG meeting minutes) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ian Brown writes: > > Without stating anything, the critical bit would wreck the signatures on > > all keys using this feature. Something more than "reserved for future > > use" needs to be said. I'd prefer, " The critical bit may be safely > > ignored for this field".. > > Sounds good to me. Same here. In fact I think Ryan Anderson's suggest an improvement over the previous consensus of "reserve for future use", so now we have: "reserve for future use; criticality bit does not apply for this field". So where are we at here, we have 3 or 4 list members saying that this is their preferred semantics for this section, plus many saying the same thing in the discussion last year. Any naysayers? Otherwise would the active editor of said document be interested to amend the document appropriately and post the suggested ammendment for approval. Would it help if some one wrote a few sentences of specific wording to put in there? Thanks, Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA20823 for ietf-open-pgp-bks; Tue, 27 Jan 1998 11:53:11 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA20819 for ; Tue, 27 Jan 1998 11:53:03 -0800 (PST) Received: from luke.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 27 Jan 1998 19:57:41 +0000 X-Mailer: exmh version 1.6.6 3/24/96 To: Ryan Anderson cc: OpenPGP mailing list Subject: Re: OpenPGP WG meeting minutes In-reply-to: Your message of "Tue, 27 Jan 1998 13:53:07 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Jan 1998 19:57:39 +0000 Message-ID: <949.885931059@cs.ucl.ac.uk> From: Ian BROWN Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > Without stating anything, the critical bit would wreck the signatures on > all keys using this feature. Something more than "reserved for future > use" needs to be said. I'd prefer, " The critical bit may be safely > ignored for this field".. Sounds good to me. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA20418 for ietf-open-pgp-bks; Tue, 27 Jan 1998 10:51:21 -0800 (PST) Received: from michonline.com (www.michonline.com [152.160.183.192]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA20414 for ; Tue, 27 Jan 1998 10:51:14 -0800 (PST) Received: from localhost (ryan@localhost) by michonline.com (8.8.5/8.8.5) with SMTP id NAA11766; Tue, 27 Jan 1998 13:53:20 -0500 (EST) Date: Tue, 27 Jan 1998 13:53:07 -0500 (EST) From: Ryan Anderson X-Sender: ryan@king To: Ian Brown cc: Bill Stewart , OpenPGP mailing list Subject: Re: OpenPGP WG meeting minutes In-Reply-To: <34CC6BDD.A6D7A5C9@cs.ucl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Mon, 26 Jan 1998, Ian Brown wrote: > > The ARR stuff was explicitly designed so that implementations that didn't > > want to implement it could ignore it safely; it's hard to undo that. > > Leave it alone for the standard > > That's all I'm asking, and seemed to be the consensus of the group - > document subpacket 10 as "reserved for future use" with no other > comment. This did not seem to be what Jon Callas decided at the IETF > meeting. > Withoutt stating anything, tge critical bit would wreck the signatures on all keys using this feature. Something more than "reserved for future use" needs to be said. I'd prefer, " The critical bit may be safely ignored for this field".. Ryan anderson PGP fp: 7E 8E C6 54 96 AC D9 57 E4 F8 AE 9C 10 7E 78 C9 print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Tue, 27 Jan 1998 10:02:54 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id TAA03485 for ietf-open-pgp@imc.org; Tue, 27 Jan 1998 19:07:48 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Formal Draft Date: 27 Jan 1998 18:07:48 GMT Organization: IKS GmbH Jena Lines: 8 Message-ID: NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk As discussed with John, I'm working on a formal specification of the OpenPGP message format. At the moment it's a machine readable syntax and partially semantics definition. This specification should be as small as possible and should be a slow (sic!) reference implementation. ftp://ftp.iks-jena.de/pub/mitarb/lutz/crypt/software/pgp/OpenPGP/ draft-ietf-openpgp-formal-YYYY-MM-DD.tgz - current snapshot draft-ietf-openpgp-formal.changes - timeline & history Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA08678 for ietf-open-pgp-bks; Mon, 26 Jan 1998 10:55:34 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA08674 for ; Mon, 26 Jan 1998 10:55:23 -0800 (PST) Received: from [205.180.136.24] (pgp24.pgp.com [205.180.136.24]) by fusebox.pgp.com (8.8.7/8.8.7) with ESMTP id KAA09211; Mon, 26 Jan 1998 10:59:02 -0800 (PST) X-Sender: vinnie@mail.pgp.com Message-Id: In-Reply-To: <3.0.3.32.19980124212056.009f5a00@cybercash.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Jan 1998 10:57:46 -0800 To: Carl Ellison From: Vinnie Moscaritolo Subject: Re: SPKI in OpenPGP format Cc: spki@c2.net, ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I am going to try to answer a number of comments from Carl an Bill here. let me summerize my question, I belive that a SPKI cert can be represented by using an OpenPGP standalone sig with the follwoing form: VALIDITY - represented by the signature creation/expiration fields ISSUER - represented by the Key ID field. SUBJECT - notation value/data pair (SPKI_SUBJ) AUTHORIZATION - notation value/data pair (SPKI_AUTH) DELEGATION - notation value/data pair (SPKI_DELEG) The notation records are a type/value structure that could contain a SPKI statement. It could be as simple as having a type 'SPKI' followed by an encapsulated SPKI record or as above I am shifting the Validity and Issuer fields to the standard standalone sig fields. An OpenPGP parser doesnt have to understand the notation data, it can just check that the signature and validity dates work and pass up the notation data to it's client for further processing. But I am not asking to extend the the OpenPGP standard in any way, the notation fields are already there and there is nothing in the proposed standard that enforces how a notation is used. This doesnt really break either of the standards, its just a way to encapulate a SPKI statement into an OPenPGP form, > What features of SPKI do you believe PGP could benefit from? I am trying to build a Public Key authorized User auth module for managing file system access. > Can we translate from PGP to SPKI canonical format easily? absolutely. and that might be the key here, there is nothing that prevents the data from being translated from one form to another. The above form simply lets allows the SPKI information to be carried in an openPGP packet. One question though, judging from my responses I think I might have misunderstood the Subject field. I was suggest that subject also be a Notation value/data pair that contained the keyID or maybe fingerprint/alg/keyID of the subject.. The current keyservers out there don't index on fingerprints, just keyIDs.. this is a problem that OpenPGP 2 needs to solve, they need to extend the keyID to a long enough field that it canbe replaced with a fingerprint. I was using the key ID to do a lookup, then comparing the fingerprints and algorithms to ensure I was using the right one. this might be more of an implementation issue. __________________________________________________________________________ Vinnie Moscaritolo Chief Consulting Engineer Total Network Security 555 Twin Dolphin Drive Network Associates, Inc. Suite 570 415.572.0430 Redwood Shores, CA 94065 Fingerprints: DE60 DB68 8E17 2A3F 60AE A933 88F1 F50E 070A 5CFF (DSS) 1 if by land, 2 if by sea. Paul Revere - encryption 1775 __________________________________________________________________________ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA08445 for ietf-open-pgp-bks; Mon, 26 Jan 1998 10:28:16 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA08441 for ; Mon, 26 Jan 1998 10:28:12 -0800 (PST) Received: from [205.180.136.24] (pgp24.pgp.com [205.180.136.24]) by fusebox.pgp.com (8.8.7/8.8.7) with ESMTP id KAA08869; Mon, 26 Jan 1998 10:32:52 -0800 (PST) X-Sender: vinnie@mail.pgp.com Message-Id: In-Reply-To: <6951.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Jan 1998 10:26:23 -0800 To: "William Allen Simpson" From: Vinnie Moscaritolo Subject: Re: SPKI in OpenPGP format Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On 1/25/98, men from black helicopters forced William Allen Simpson to write: >Vinnie, I had already posted a combined format many months ago to these >lists. I called it "Pretty Simple PKI". Maybe I should post the draft >again. > please send me a copy, I must have missed it. __________________________________________________________________________ Vinnie Moscaritolo Chief Consulting Engineer Total Network Security 555 Twin Dolphin Drive Network Associates, Inc. Suite 570 415.572.0430 Redwood Shores, CA 94065 Fingerprints: DE60 DB68 8E17 2A3F 60AE A933 88F1 F50E 070A 5CFF (DSS) 1 if by land, 2 if by sea. Paul Revere - encryption 1775 __________________________________________________________________________ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA07809 for ietf-open-pgp-bks; Mon, 26 Jan 1998 09:20:58 -0800 (PST) Received: from mail.the-wire.com (mail.the-wire.com [198.53.192.5]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id JAA07804 for ; Mon, 26 Jan 1998 09:20:53 -0800 (PST) Received: from [205.206.36.71] (rguerra.the-wire.com [205.206.36.71]) by mail.the-wire.com (8.8.8/8.8.8) with ESMTP id MAA03191; Mon, 26 Jan 1998 12:22:54 -0500 (EST) X-Sender: rguerra@mail.the-wire.com (Unverified) Message-Id: Mime-Version: 1.0 X-PGP-RSAkey: http://pgp5.ai.mit.edu:11371/pks/lookup?op=get&search=0x89619BC5 X-PGP-DSSkey: http://pgp5.ai.mit.edu:11371/pks/lookup?op=index&search=0x4B408E7B X-Face: #Y7%!=h:R1Q;{.%v{UB%gXW%2Z^p_P:G|Ndp8"*GW_*ie/|$Or(T?UFC*lC1d /U^Owx'*swpm9IyR9Ms)&`U+ Date: Mon, 26 Jan 1998 12:21:43 -0500 To: ietf-open-pgp@imc.org, mac-crypto@vmeng.com, pgp-users@joshua.rivertown.net From: Robert Guerra Subject: April 23-24:PGP Keysigning session..can one be arranged? Cc: pks@certicom.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Content-Transfer-Encoding: quoted-printable I would like to know if it would be possible to arrange a PGP keysigning session among those who will be in Toronto for the below mentioned conference. No doubt it is an opportunity to have people from "out of town" participate, and hence increase the parties participating in the keysigning session. comments/suggestions most welcome. regards robert - -- conference details below -- =46rom: Karen Brown Newsgroups: comp.security Subject: ELLIPTIC CURVE CRYPTOGRAPHY (ECC) SEMINAR - April 23-24, 1998 Date: Fri, 23 Jan 1998 10:34:00 -0800 ELLIPTIC CURVE CRYPTOGRAPHY (ECC) SEMINAR An Advanced Seminar On Elliptic Curve Cryptography and the Ideal Way to Learn the Techniques of Elliptic Curve Cryptography Lead by: Dr. Scott Vanstone Renowned ECC Pioneer and Certicom Co-Founder and Chief Cryptographer April 23 and 24, 1998 (following the Certicom PKS '98 Conference) - Four Seasons Hotel, Toronto, Canada The Elliptic Curve Cryptography (ECC) Seminar offers a comprehensive overview of ECC and is lead by Dr. Vanstone, one of the world's leading cryptographers. This seminar is a convenient intensive introduction to the algorithms and implementation techniques of ECC. The ECC Seminar Includes: =B7 an overview of relevant abstract algebra =B7 motivation for and construction of the group of points formed from an elliptic curve over a finite field =B7 implementation issues for both hardware and software =B7 security issues of the ECDLP (Elliptic Curve Discrete Logarithm Problem) =B7 an overview of protocols using ECC for signature/verification, key agreement, key transport, and encryption/decryption =B7 representations, point compression, security considerations, and other issues affecting implementations of ECC in both hardware and software At the end of the seminar, you will understand how to: =B7 formulate an elliptic curve group =B7 construct a public-key cryptosystem from this group =B7 evaluate the difficulty of the Elliptic Curve Discrete Logarithm Problem (ECDLP) on which the security of ECC is based =B7 efficiently implement ECC in both hardware and software Course prerequisites: =B7 an understanding of abstract algebra =B7 a general knowledge of public-key cryptosystems =B7 a degree in Mathematics, Engineering or Computer Science. =46or more information and or register, visit the Certicom PKS website or contact Certicom www.certicom.com/pks pks@certicom.com 905-501-3836 (Canada) 650-312-7977 (USA) Robert Guerra - PGP public key available on PGP key servers Email-> mailto:az096@freenet.toronto.on.ca Home Page-> http://www.geocities.com/CapitolHill/3378 -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.5.3 iQEVAwUBNMzHEYs5aKqJYZvFAQEL7wgAxsVD/Q/D8HsJvagJfypmaclMPWkmo9gW Ut4kDLBxGwWr8T/z6AEnecT1XQQbXLOlWcbxKx2QC13RUBwIpT2QrPaJfCl1njwW vBw+q0JH8LUun7UflcBL1HNT+QuqxOL/6mjoj2I8WQ0gnfvMrstemzcmA2TJ8PDU ltir/9HW6Cmp6B2BOpRMpMP9Xi7fiafSfLTNmSeMuSvbhkl8PsPPhWUQfuuiB7Ql F0AlrItxi73hKZOHC2yauGcyZHtAtZL8UoQPpR0RF+a4tEFz3w8UrGlsPajOpbYh NPasNGIUboCcnmC+7aX7T2YBC2r+poipSp7hsw4BPzjvCduS8vP/0Q== =Xpap -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id CAA04821 for ietf-open-pgp-bks; Mon, 26 Jan 1998 02:54:01 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.8/8.7.3) with SMTP id CAA04817 for ; Mon, 26 Jan 1998 02:53:56 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 26 Jan 1998 10:57:40 +0000 Message-ID: <34CC6BDD.A6D7A5C9@cs.ucl.ac.uk> Date: Mon, 26 Jan 1998 10:56:29 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Bill Stewart CC: OpenPGP mailing list Subject: Re: OpenPGP WG meeting minutes References: <3.0.5.32.19980125164713.00870100@popd.ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > The ARR stuff was explicitly designed so that implementations that didn't > want to implement it could ignore it safely; it's hard to undo that. > Leave it alone for the standard That's all I'm asking, and seemed to be the consensus of the group - document subpacket 10 as "reserved for future use" with no other comment. This did not seem to be what Jon Callas decided at the IETF meeting. As Ian Grigg said, documenting the Additional Receipient Request in a neutral way is impossible with the conflicting variety of opinions in this group. The only fair way to deal with it is to not mention it at all. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id WAA02311 for ietf-open-pgp-bks; Sun, 25 Jan 1998 22:57:47 -0800 (PST) Received: from netcomsv.netcom.com (uucp1-b.netcom.com [163.179.3.1]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id WAA02307 for ; Sun, 25 Jan 1998 22:57:41 -0800 (PST) Received: from ca07b8bl.bns.att.com (boi-id1-06.ix.netcom.com [204.32.193.38]) by netcomsv.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.01)) with SMTP id XAA14176; Sun, 25 Jan 1998 23:02:30 -0800 (PST) Message-Id: <3.0.5.32.19980125164713.00870100@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sun, 25 Jan 1998 16:47:13 -0700 To: Ian BROWN From: Bill Stewart Subject: Re: OpenPGP WG meeting minutes Cc: OpenPGP mailing list In-Reply-To: <631.885739874@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 02:51 PM 1/25/98 +0000, Ian BROWN wrote: >> ARR subpacket - This will be defined as optional. >> The draft will say explicitly that the implementation >> can do anything it wants with this. It does not >> have to use it. > >I was surprised, to say the least, to see this in the minutes of the December >meeting. In the weeks running up to the standard, extensive discussion over >this topic occurred. An almost complete consensus formed around the view that >subpacket 10 should be "reserved for future/PGP use" with no other comment. >This is a compromise solution that allows PGP Inc. to persue their message >recovery scheme while retaining compatibility with other implementations that >do not. > >As Ian Grigg said, there is certainly no consensus within the WG that this >feature should be included. It should therefore not be "blessed" by >documentation within the standard. Fundamentally, your choices are to - leave the structure that way (either documenting it or not), or - define some alternate required behaviour for #10, like reject the key (which is identical to the behaviour with the critical bit set :-) or display an error message or mail the ARR key to aclu.org, or - replace the while subpacket structure with something completely different, forcing PGP to be non-compliant and to use some other extension mechanism for the evil option. (Basically unacceptable.) The ARR stuff was explicitly designed so that implementations that didn't want to implement it could ignore it safely; it's hard to undo that. Leave it alone for the standard, or perhaps also define a SHOULD error message for unsupported subpacket types. Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id GAA24669 for ietf-open-pgp-bks; Sun, 25 Jan 1998 06:51:45 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.8/8.7.3) with SMTP id GAA24665 for ; Sun, 25 Jan 1998 06:51:41 -0800 (PST) Received: from luke.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 25 Jan 1998 14:51:15 +0000 X-Mailer: exmh version 1.6.6 3/24/96 To: "John W. Noerenberg" cc: OpenPGP mailing list Subject: Re: OpenPGP WG meeting minutes In-reply-to: Your message of "Mon, 19 Jan 1998 13:03:38 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 Jan 1998 14:51:14 +0000 Message-ID: <631.885739874@cs.ucl.ac.uk> From: Ian BROWN Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > ARR subpacket - This will be defined as optional. > The draft will say explicitly that the implementation > can do anything it wants with this. It does not > have to use it. I was surprised, to say the least, to see this in the minutes of the December meeting. In the weeks running up to the standard, extensive discussion over this topic occurred. An almost complete consensus formed around the view that subpacket 10 should be "reserved for future/PGP use" with no other comment. This is a compromise solution that allows PGP Inc. to persue their message recovery scheme while retaining compatibility with other implementations that do not. As Ian Grigg said, there is certainly no consensus within the WG that this feature should be included. It should therefore not be "blessed" by documentation within the standard. The IETF Working Group Guidlines (RFC 1603) say that: > decisions reached during IETF meetings are NOT final, but must be > conveyed to the mailing list to verify WG consensus. I think this issue is far from closed. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id GAA24609 for ietf-open-pgp-bks; Sun, 25 Jan 1998 06:31:39 -0800 (PST) Received: from merit.edu (merit.edu [198.108.1.42]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id GAA24605 for ; Sun, 25 Jan 1998 06:31:34 -0800 (PST) Received: from Bill.Simpson.DialUp.Mich.Net (pm368-23.dialip.mich.net [207.75.186.123]) by merit.edu (8.8.7/8.8.5) with SMTP id JAA14838 for ; Sun, 25 Jan 1998 09:36:30 -0500 (EST) Date: Sun, 25 Jan 98 14:09:04 GMT From: "William Allen Simpson" Message-ID: <6952.wsimpson@greendragon.com> To: spki@c2.net Cc: ietf-open-pgp@imc.org Subject: Re: SPKI in OpenPGP format Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Vinnie, I had already posted a combined format many months ago to these lists. I called it "Pretty Simple PKI". Maybe I should post the draft again. The PGP key itself serves as the subject. And I used the old literal to end of packet (no length) to serve as the "()" element grouping. The current name element is simply interpreted to be tag "(name )". This construct would allow extension of current PGP so that you could sign 2 or more user names in a group at once, rather than the current one at a time limitation, and incorporate SDSI names to be signed. It should be easy to modify the current libraries to interpret the elements, and translate between them, without any confusion with older PGP formats (they would stop on the literal). I checked the sources, everything looked OK. I could not get agreement on the SPKI list that a binary form would be the canonical form (very important for signing), and the textual form would merely be a visual translation for human editting programs. A lot of us have desired this, but no overwhelming consensus was achieved (not enough to get Ellison to change). Also, key lengths would need to be bit-length instead of byte-length (very important for backward PGP element compatibility). Ellison adamantly refused this point. On the OpenPGP side, there seemed to be general agreement that the PGP 5 draft formats needed to be finished before worrying about extensions. So, yes, it could be done easily and elegantly, but the parties lack the political will. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA19568 for ietf-open-pgp-bks; Sat, 24 Jan 1998 18:18:52 -0800 (PST) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by mail.proper.com (8.8.8/8.7.3) with SMTP id SAA19560 for ; Sat, 24 Jan 1998 18:18:43 -0800 (PST) Received: by callandor.cybercash.com; id VAA02614; Sat, 24 Jan 1998 21:05:56 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma002607; Sat, 24 Jan 98 21:05:50 -0500 Received: from carltecra ([192.168.33.18]) by cybercash.com (4.1/SMI-4.1) id AA10761; Sat, 24 Jan 98 21:24:11 EST Message-Id: <3.0.3.32.19980124212056.009f5a00@cybercash.com> X-Sender: cme@cybercash.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 24 Jan 1998 21:20:56 -0500 To: Vinnie Moscaritolo From: Carl Ellison Subject: Re: SPKI in OpenPGP format Cc: spki@c2.net, ietf-open-pgp@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- At 03:13 PM 1/23/98 -0800, Vinnie Moscaritolo wrote: >Here is a possible way to represent a SPKI certifcate in OpenPGP format >OpenPGP added a utility field called a notation that could be used >to hold SPKI strings. Its more of a binary (un human readble version) >but it does maintain the spirit of SPKI. Vinnie, I think I understand what you're trying here, but I wonder if you want to introduce all the complexity of SPKI in your format. For example, if I were to be designing this, I wouldn't create an SPKI SUBJECT field. The subject can be the key to which this information is attached. [Of course, I'm assuming that there would be normal SPKI certs living outside the structure. If you're not assuming that, then I need to think some more.] To me, PGP suffers mostly from the lack of SDSI names. I don't see PGP used to do general purpose access control -- the task for which SPKI's auth fields were created. So, the subset I would concentrate on in PGP is SDSI names. Doing that requires some design work at the user interface level, rather than just in data structures. What features of SPKI do you believe PGP could benefit from? Can we translate from PGP to SPKI canonical format easily? Do we need to express everything SPKI can in the PGP format? - Carl -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.5.3 iQCVAwUBNMqhhxN3Wx8QwqUtAQEdtAQAkRC+Nd9Bcz1ICyWdc+CreAJJEFcs8Gun v0NFH5s9SwGfHgi7myBanIiauEXcG9Qq4pth1TGALSgAQtL1yIxMVuxZfvU6QyJ8 4FiD7tqawqwMue+UGww3eMhiwInS2oIWoaddkmZ0YIANfy6+4ANYz6m64PbeayCM W8+QgmsMElU= =s54R -----END PGP SIGNATURE----- +------------------------------------------------------------------+ |Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme | |CyberCash, Inc. http://www.cybercash.com/ | |207 Grindall Street PGP 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 | |Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 | +------------------------------------------------------------------+ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA17677 for ietf-open-pgp-bks; Sat, 24 Jan 1998 14:16:36 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA17673 for ; Sat, 24 Jan 1998 14:16:32 -0800 (PST) Received: from s20.term1.sb.rain.org (s16.term2.sb.rain.org [198.68.144.176]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id OAA22671 for ; Sat, 24 Jan 1998 14:21:21 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id OAA19889 for ietf-open-pgp@imc.org; Sat, 24 Jan 1998 14:06:22 -0800 Date: Sat, 24 Jan 1998 14:06:22 -0800 From: Hal Finney Message-Id: <199801242206.OAA19889@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: Possible Error/Oversight in Encrypted Session Key Pkt format Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Lindsay Mathieson, , writes: > For Encrypted Session Key Packets (Section 5.1) the OpenPGP spec states: > > The encrypted value "m" in the above formulas is derived from the > session key as follows. First the session key is prepended with a > one-octet algorithm identifier that specifies the conventional > encryption algorithm used to encrypt the following Symmetrically > Encrypted Data Packet. *Then a two-octet checksum is appended which is > equal to the sum of the preceding octets, including the algorithm > identifier and session key, modulo 65536.* > > The problem is with the checksum, the spec states that it includes the > algorithm identifier, whereas in PGP 2.x it actually doesn't, it only > includes the session key itself. I'm not sure is this is the case for PGP > 5.x though. Also it might be handy to mention that the checksum is in MSB > ordering. > > So perhaps if it was changed to: > > Then a two-octet checksum in MSB order is appended, which is > equal to the sum of the preceding session key octets, modulo 65536. You are correct, I misread the code when I provided this information to Jon. The alg ID is not included in the checksum in 5.X or in 2.X. We should correct the draft spec. Hal Finney hal@pgp.com hal@rain.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA13810 for ietf-open-pgp-bks; Sat, 24 Jan 1998 05:50:56 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id FAA13799 for ; Sat, 24 Jan 1998 05:50:50 -0800 (PST) Message-Id: <199801241350.FAA13799@mail.proper.com> Received: (qmail 11120 invoked from network); 24 Jan 1998 13:55:41 -0000 Received: from ts5131.powerup.com.au (HELO lindsay) (202.139.237.31) by enterprise.powerup.com.au with SMTP; 24 Jan 1998 13:55:41 -0000 Date: 25 Jan 1998 14:43:34 GMT From: Lindsay Mathieson Subject: Possible Error/Oversight in Encrypted Session Key Pkt format To: IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Release Vs 2.7 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk For Encrypted Session Key Packets (Section 5.1) the OpenPGP spec states: The encrypted value "m" in the above formulas is derived from the session key as follows. First the session key is prepended with a one-octet algorithm identifier that specifies the conventional encryption algorithm used to encrypt the following Symmetrically Encrypted Data Packet. *Then a two-octet checksum is appended which is equal to the sum of the preceding octets, including the algorithm identifier and session key, modulo 65536.* The problem is with the checksum, the spec states that it includes the algorithm identifier, whereas in PGP 2.x it actually doesn't, it only includes the session key itself. I'm not sure is this is the case for PGP 5.x though. Also it might be handy to mention that the checksum is in MSB ordering. So perhaps if it was changed to: Then a two-octet checksum in MSB order is appended, which is equal to the sum of the preceding session key octets, modulo 65536. -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Release Vs 2.7, on January 25, 1998, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA15199 for ietf-open-pgp-bks; Fri, 23 Jan 1998 21:37:10 -0800 (PST) Received: from netra01.origin.com.br (netra01.origin.com.br [200.246.218.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA15195 for ; Fri, 23 Jan 1998 21:37:05 -0800 (PST) From: vE0RQ1lEW@beeche1s.net Received: from oIEI8aUy1 (1Cust118.tnt26.atl2.da.uu.net [208.255.221.118]) by netra01.origin.com.br (8.8.6/8.8.5) with SMTP id DAA28639; Sat, 24 Jan 1998 03:10:41 -0200 (EDT) DATE: 23 Jan 98 12:21:21 AM Message-ID: TO: happy@just4u21.com SUBJECT: Are You Happy! Sender: owner-ietf-open-pgp@imc.org Precedence: bulk There is brilliant information available to you, that will enable you to fully understand yourself and everybody else. This knowledge can benefit you tremendously in many ways. It can help you to get the very best out of your career, or discover your most suitable new career, and of course being happy at work, really improves the finances. It can also really enhance your love life. If you're in a relationship, it works great, because you are able to fully understand your own and your partner's emotions and motivations. If you're not, you will know exactly what you want from your perfect mate and what they will find attractive about you. Another big advantage to becoming balanced and happy is that good health runs hand in hand. Take a closer look two free pages of information at: http://www.po9.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA11178 for ietf-open-pgp-bks; Fri, 23 Jan 1998 15:09:41 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA11174 for ; Fri, 23 Jan 1998 15:09:37 -0800 (PST) Received: from [205.180.136.45] (pgp24.pgp.com [205.180.136.24]) by fusebox.pgp.com (8.8.7/8.8.7) with ESMTP id PAA10358; Fri, 23 Jan 1998 15:14:22 -0800 (PST) X-Sender: vinnie@mail.pgp.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Jan 1998 15:13:33 -0800 To: spki@c2.net, ietf-open-pgp@imc.org From: Vinnie Moscaritolo Subject: SPKI in OpenPGP format Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Here is a possible way to represent a SPKI certifcate in OpenPGP format OpenPGP added a utility field called a notation that could be used to hold SPKI strings. Its more of a binary (un human readble version) but it does maintain the spirit of SPKI. the packet format is further descreibed in sect 5.2.2. of the openPGP spec. just a thought. SPKI packet represented in OpenPGP Standalone signature packet size hex-value desc Packet Header ------------- 1 8B Ptag 10 0010 11 | | '-- 3 = indeterminate len | '-------- 2 = Signature Packet '------------ old packet format Version 4 Signature packet 1 04 version number: (4). 1 02 Signature Types: Standalone signature 1 XX public key algorithm. ( DSA = 0x11 ) 1 XX hash algorithm ( SHA1 = 0x02 ) Hashed SubPacket Data 2 XXXX Hashed subpacket len --- ------------- 1 02 2 = signature creation time VALIDITY 4 XX XX XX XX Signature creation time --- 1 03 3 = signature expiration time 4 XX XX XX XX Signature creation time --- ------------- 1 10 16 = issuer key ID ISSUER 8 XX... Key ID of issuer --- ------------- 1 14 20 = notation data AUTHORIZATION 4 0000 0000 (4 octets of flags) 2 0009 - name length 2 XXXX - value length, 9 'SPKI_AUTH' - name data N XX.... - value data --- ------------- 1 14 20 = notation data SUBJECT 4 0000 0000 (4 octets of flags) 2 000C - name length 2 0008 - value length, 8 'SPKI_SUBJECT' - name data N XX.... - Key ID of subject --- ------------- 1 14 20 = notation data DELEGATION 4 0000 0000 (4 octets of flags) 2 000A - name length 2 0000 - value length the existance of this field means 10 'SPKI_DELEG' - name data that the subject may delagate the priv --- UnHashed SubPacket Data 2 00 00 UnHashed subpacket len (not used) Signature Data 2 XXXX - Two-octet field holding left 16 bits of signed hash value. N XXXX... - One or more multi-precision integers comprising the signature. __________________________________________________________________________ Vinnie Moscaritolo Chief Consulting Engineer Total Network Security 555 Twin Dolphin Drive Network Associates, Inc. Suite 570 415.572.0430 Redwood Shores, CA 94065 Fingerprints: DE60 DB68 8E17 2A3F 60AE A933 88F1 F50E 070A 5CFF (DSS) 1 if by land, 2 if by sea. Paul Revere - encryption 1775 __________________________________________________________________________ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA06293 for ietf-open-pgp-bks; Fri, 23 Jan 1998 07:54:18 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA06289 for ; Fri, 23 Jan 1998 07:54:09 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id QAA00667 for ietf-open-pgp@imc.org; Fri, 23 Jan 1998 16:58:51 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: proposed FP sig subpacket type Date: 23 Jan 1998 15:58:51 GMT Organization: IKS GmbH Jena Lines: 19 Message-ID: References: NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Vinnie Moscaritolo wrote: >I would like to suggest that a Issuer Key Fingerprint be added to the >acceptable Signature Subpacket types (sec 5.2.2.2). I suspect that this >fingerprint should be an MPI since its a hash of the Issuer Signing key Yes, there is a field for this purpose. >From the OpenPGP Reference implementation to be: sigsub_keyid: lex_token '\x10' keyid ; No, it's not a MPI. keyid: {lex_octets(8)} octets {memcpy($$, $2.field, 8); free($2.field)} ; PS: Yes, I talked to John before. There will be a formal specification, too. (make draft at my system...) It will be GPLed. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA06176 for ietf-open-pgp-bks; Fri, 23 Jan 1998 07:26:35 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA06172 for ; Fri, 23 Jan 1998 07:26:30 -0800 (PST) Received: from whgiii (cppp16.dotstar.net [208.143.93.116]) by users.invweb.net (8.8.7/8.8.7) with SMTP id KAA12980 for ; Fri, 23 Jan 1998 10:48:56 -0500 Message-Id: <199801231548.KAA12980@users.invweb.net> From: "William H. Geiger III" Date: Fri, 23 Jan 98 09:29:28 -0500 To: ietf-open-pgp@imc.org Subject: Please Fix X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Could someone please fix this as I receive a bounce from PGP Inc. every time I post to the list: >Thank you for your email. The requested user now receives mail at >jbhoward@intrex.net > >For PGP-related issues, email info@pgp.com. > >Thanks. > >Pretty Good Privacy, Inc. >http://www.pgp.com Thanks, - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- Tag-O-Matic: Windows? WINDOWS?!? Hahahahahehehehehohohoho... -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNMip1I9Co1n+aLhhAQH+XQQAiorfQWwW5E3TCwlPcIbdRSQnpY5hrGVo nw+0jBp9j3dG6BCwBsEpWxRv/X/8yJ558aRmWyPyay6echY4KxqJba8WxxVy2WLX SHQiC9PsLB+RCKMkDAltDAXuvnOtE8dKLnMVSsR0klcKsOo807AKNOpnhDo5YgXh FSsZantu1qQ= =da7d -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA06087 for ietf-open-pgp-bks; Fri, 23 Jan 1998 07:15:48 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA06083 for ; Fri, 23 Jan 1998 07:15:41 -0800 (PST) Received: from whgiii (cppp16.dotstar.net [208.143.93.116]) by users.invweb.net (8.8.7/8.8.7) with SMTP id KAA12885; Fri, 23 Jan 1998 10:37:17 -0500 Message-Id: <199801231537.KAA12885@users.invweb.net> From: "William H. Geiger III" Date: Fri, 23 Jan 98 08:58:11 -0500 To: Bill Stewart In-Reply-To: <3.0.5.32.19980123002125.0085c470@popd.ix.netcom.com> Cc: Hiroyuki.Yamada@Japan.Sun.COM (Hiroyuki Yamada), ietf-open-pgp@imc.org Subject: Re: The canonical in rfc2015 X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <3.0.5.32.19980123002125.0085c470@popd.ix.netcom.com>, on 01/23/98 at 03:21 AM, Bill Stewart said: >At 02:46 PM 1/23/98 +0900, Hiroyuki Yamada wrote: >>I have a question about PGP signed data in section 5-(1)(2)(3) >>of rfc2015. It requires for end of each lines instead >>of . Could anybody have any reason for it ? >Different operating systems have different conventions for >representing the end of a line. Unix uses ( = ). >MS-DOS uses as do some other systems. I think >Macintoshes may use . So if you want to sign a document on one >system and verify the signature on the other, >you have to know which convention is being used, >or hope that the your operating system, the signer's operating system, or >some glue in between did not change the newline. >If you always sign the same version, this doesn't happen, >and probably will not do Bad Things on most systems. Isn't pretty much the standard in the RFC's ? IIRC RFC733 onward all specify . Since RFC733 and for the most part RFC822 pre-date the PC revolution I would imagine that this was the standard convention for the machines being used by ARPANET at the time (I was still using an IBM1130 then and I don't remember what it used). Perhaps a Net historian could step in and clarify the matter. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- Tag-O-Matic: This is a TAG-O-Matic Multi-line Sample Tag -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNMinGY9Co1n+aLhhAQFTVwP/QeCQC/it39LW/vd0EhDln4z0KuXCOcOR 6DC2jfg908T9I7TUr0/Z8KprkW6mkLjCrbV0E4hG6DWvrWcXRW8Vc4IX/O2O1zAX wTDEGmoNfG55Qnimn0uGB2qWZPuCknfDAIM69VRWbTPcaCPTFHlt/+C9JM5NA9zI WxLWUO+BKpw= =gkP0 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA01792 for ietf-open-pgp-bks; Fri, 23 Jan 1998 00:55:03 -0800 (PST) Received: from netcomsv.netcom.com (uucp1-b.netcom.com [163.179.3.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA01785 for ; Fri, 23 Jan 1998 00:54:59 -0800 (PST) Received: from ca07b8bl.bns.att.com (pax-ca11-07.ix.netcom.com [204.30.66.167]) by netcomsv.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.01)) with SMTP id AAA20216; Fri, 23 Jan 1998 00:59:38 -0800 (PST) Message-Id: <3.0.5.32.19980123002125.0085c470@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 23 Jan 1998 00:21:25 -0800 To: Hiroyuki.Yamada@Japan.Sun.COM (Hiroyuki Yamada), ietf-open-pgp@imc.org From: Bill Stewart Subject: Re: The canonical in rfc2015 In-Reply-To: <199801230546.OAA03166@kirin.Japan.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 02:46 PM 1/23/98 +0900, Hiroyuki Yamada wrote: >I have a question about PGP signed data in section 5-(1)(2)(3) >of rfc2015. It requires for end of each lines instead >of . Could anybody have any reason for it ? Different operating systems have different conventions for representing the end of a line. Unix uses ( = ). MS-DOS uses as do some other systems. I think Macintoshes may use . So if you want to sign a document on one system and verify the signature on the other, you have to know which convention is being used, or hope that the your operating system, the signer's operating system, or some glue in between did not change the newline. If you always sign the same version, this doesn't happen, and probably will not do Bad Things on most systems. Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA00764 for ietf-open-pgp-bks; Thu, 22 Jan 1998 21:41:45 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id VAA00760 for ; Thu, 22 Jan 1998 21:41:41 -0800 (PST) Received: from Japan.Sun.COM ([129.158.31.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA13473 for ; Thu, 22 Jan 1998 21:45:57 -0800 Received: from kirin.Japan.Sun.COM by Japan.Sun.COM (SMI-8.6/SMI-SVR4-sd.fkk200) id OAA12288; Fri, 23 Jan 1998 14:45:19 +0900 Received: by kirin.Japan.Sun.COM (SMI-8.6/SMI-SVR4) id OAA03166; Fri, 23 Jan 1998 14:46:18 +0900 Date: Fri, 23 Jan 1998 14:46:18 +0900 From: Hiroyuki.Yamada@Japan.Sun.COM (Hiroyuki Yamada) Message-Id: <199801230546.OAA03166@kirin.Japan.Sun.COM> To: ietf-open-pgp@imc.org Subject: The canonical in rfc2015 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I have a question about PGP signed data in section 5-(1)(2)(3) of rfc2015. It requires for end of each lines instead of . Could anybody have any reason for it ? Thank you, hiro Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA26804 for ietf-open-pgp-bks; Thu, 22 Jan 1998 11:35:56 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA26800 for ; Thu, 22 Jan 1998 11:35:52 -0800 (PST) Received: from [205.180.136.45] (shiva5.pgp.com [205.180.136.45]) by fusebox.pgp.com (8.8.7/8.8.7) with ESMTP id LAA21042 for ; Thu, 22 Jan 1998 11:40:38 -0800 (PST) X-Sender: vinnie@mail.pgp.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Jan 1998 11:39:55 -0800 To: ietf-open-pgp@imc.org From: Vinnie Moscaritolo Subject: proposed FP sig subpacket type Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I would like to suggest that a Issuer Key Fingerprint be added to the acceptable Signature Subpacket types (sec 5.2.2.2). I suspect that this fingerprint should be an MPI since its a hash of the Issuer Signing key While I was trying to write some code that will build and use standalone signatures it occured to me that in order to test that a standalone signature packet is valid you either need to compare it against the Issuer's Key Fingerprint or test the sig against a possible number of keyid matches. I feel that Issuer Key ID is mostly useful for quick lookup a key, but offers a higher chance of key collision than a fp would, so that having both available is useful. I understand that there is mmotavation to evolve the standard away from 8 octet keyIDs to nbyte key Fp, and this thing is beter addressed in a v2 spec, but this addition in the v1 spec shouldnt break anything. (I hope) any comments? __________________________________________________________________________ Vinnie Moscaritolo tel: 415.524.6222 Pretty Good Privacy, Inc. Chief Consulting Engineer main: 415.572.0430 2121 S. El Camino Real web: http://www.pgp.com San Mateo, CA 94403 DH Key: http://keys.pgp.com:11371/pks/lookup?op=get&search=0x070A5CFF 1 if by land, 2 if by sea. Paul Revere - encryption 1775 __________________________________________________________________________ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA06381 for ietf-open-pgp-bks; Tue, 20 Jan 1998 12:05:26 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA06377 for ; Tue, 20 Jan 1998 12:05:19 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Tue, 20 Jan 1998 15:10:23 -0500 Date: Tue, 20 Jan 1998 15:09:32 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars.ceddec.com To: OpenPGP mailing list Subject: Re: OpenPGP WG meeting minutes In-Reply-To: Message-Id: <98Jan20.151023est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Mon, 19 Jan 1998, John W. Noerenberg wrote: > Here are the long delayed minutes from the IETF meeting in December. Tony > Mione recorded them, and I've annotated them slightly. > > 40th IETF, Washington, DC > OpenPGP Working Group Meeting Minutes > 8-Dec-1997 ... > Draft : PGP Message formats (Jon Callas) > Jon discussed the most recent decisions on various open issues > in the PGP Message formats draft > (drafts-ietf-openpgp-formats-00.txt). There was some discussion > on certain points. Some decisions by Jon, et al were reversed > or modified during the discussion. ... > 2.5.3.3 Iterated/Salted String-to-key - This is long, hairy and > complicated to implement. We have considered removing it. The following should do all three variants (0,1,3), but I haven't tested them all, nor any hashtype not normally used by PGP 5.0b8. The original is at www.cryptography.org in cipcop09.tgz in the libraries directory. bp points to a buffer with the key material starting with the crypto type, and hashpass contains the user typed in password. cfbinit sets the key and initial IV for the cfb decryption: void cfbinit(unsigned char *key, unsigned char *iv0, int cipher); /*------------------------------------*/ /* string to key and initialize conventional encryption */ void getcfbkey(unsigned char **bp, unsigned char *hashpass) { unsigned int i = 0, j, k = 0, ca, ha, sa; unsigned char hbuf[256]; unsigned char hashctx[1024]; ca = *(*bp)++; /* crypto type */ sa = *(*bp)++; /* salt type */ ha = *(*bp)++; /* hash type */ if (sa & 1) { memcpy(hbuf, *bp, 8); /* salt */ memcpy(&hbuf[8], hashpass, strlen(hashpass)); *bp += 8; k = 8 + strlen(hashpass); i = k; } if (sa == 3) { i = *(*bp)++; /* postfix - hash size */ j = i >> 4; i = (i & 15) + 16; i <<= j + 6; } else if (sa == 0) { /* salt-free */ memcpy(hbuf, hashpass, strlen(hashpass)); i = strlen(hashpass); k = i; } else if (sa != 1) /* 1 = just salt, else error */ exit(-1); j = i / k; /* loops over whole text */ i = i % k; /* last loop size */ if (ha < 1 || ha > MAXHASH) exit(-1); (*hashinit[--ha]) (hashctx); while (j--) (*hashupdate[ha]) (hashctx, hbuf, k); (*hashupdate[ha]) (hashctx, hbuf, i); (*hashfinal[ha]) (hbuf, hashctx); memcpy(&hbuf[hashlen[ha]], hbuf, hashlen[ha]); memcpy(&hbuf[hashlen[ha] * 2], hbuf, hashlen[ha] * 2); cfbinit(hbuf, *bp, ca); *bp += 8; } > The rationale for its use is that: > 1-Salt perturbs encryption of strings (same string > encrypts to different values each time it > is used) > 2-Iteration adds compute time for the craker program > running a dictionary attack. > We've seen 3 options mentioned > 1) Remove it > 2) Change 8-bit float to 32 bit int > 3) Change it to a MAY > Request for comments from WG > > Comments from WG member: Options add complexity but is useful > and important. The member would not have a problem > with it if the float was changed to a 32-bit > integer (2). --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA05847 for ietf-open-pgp-bks; Tue, 20 Jan 1998 11:12:46 -0800 (PST) Received: from mail0.iij.ad.jp (mail0.iij.ad.jp [202.232.2.113]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA05843 for ; Tue, 20 Jan 1998 11:12:41 -0800 (PST) Received: from uucp1.iij.ad.jp (uucp1.iij.ad.jp [202.232.2.201]) by mail0.iij.ad.jp (8.8.8/3.6W-MAIL) with SMTP id EAA05666; Wed, 21 Jan 1998 04:17:19 +0900 (JST) Received: (from uucp@localhost) by uucp1.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id EAA21028; Wed, 21 Jan 1998 04:17:23 +0900 Received: from localhost by h2np.suginami.tokyo.jp (NX5.67c/IIJ-U1.2c) id AA21094; Wed, 21 Jan 98 04:15:14 +0900 Message-Id: <9801201915.AA21094@h2np.suginami.tokyo.jp> To: "William H. Geiger III" Cc: ulf@fitug.de, ietf-open-pgp@imc.org Reply-To: hironobu@h2np.suginami.tokyo.jp Subject: MISTY1 In-Reply-To: Your message of "Tue, 20 Jan 1998 11:32:57 EST." <199801201755.MAA10398@users.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Wed, 21 Jan 1998 04:15:13 +0900 From: Hironobu Suzuki Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >>>>> "W" == William H Geiger writes: W> Anyone unfamiliar with Misty should look at the CP archives for W> the numerous posts by Nobuki Nakatuji. It has snake-oil written W> all over it. This is exactly what is meant by 'pet' algorithm. I read some emails 'about MISTY encryption Algorithm' from CP archives. Do you mention about MISTY1 has kept secret key while encrypting? My opinions are below. 1) Design of MISTY1 assume that a secret key is a session key which will be disposed and never use it again. 2) lots of cipher program, included PGP, can't avoid "CORE DUMP ATTACK"( core-dumped running process and do "gdb core"). Because expansion key is fixed while encrypting. 3) MISTY1 is fast and is proved a strong cipher against DC, LC. I mention about Nobuki Nakatuji. I've never heard his name until 18 hours ago. Today, Nobuki e-mailed me and said "You need a permission from MITI to open your MISTY1 code on your website, don't you?". Nobuki seems he don't know about cryptography situation in Japan. Fortunately, In Japan, programs for research or programs with known technology are NOT required any permission from MITI. This export condition is described in document which was issued from MITI export department. So, there are many PGP program archive sites in Japan and you can get it. Most of Japanese cryptographers and real hackers who have made so-high-tech programs, know about it because they're must write their academic paper, AI or high-tech programs and do something like to issue Internet Draft written by Matsui-san. But Nobuki don't know about it. MISTY's references are here. [1] M. Matsui, "New Block Encryption Algorithm MISTY", Fast Software Encryption - 4th International Workshop (FSE'97), LNCS 1267, Springer Verlag, 1997, pp.54-68 [2] K. Nyberg and L.R. Knudsen, "Provable Security Against a Differential Attack", Journal of Cryptology, Vol.8, No.1, 1995, pp. 27-37 [3] K. Nyberg, "Linear Approximation of Block Ciphers", Advances in Cryptology - Eurocrypt'94, LNCS 950, Springer Verlag, 1995, pp.439-444 [4] M. Matsui, "New Structure of Block Ciphers with Provable Security Against Differential and Linear Cryptanalysis", Fast Software Encryption - Third International Workshop, LNCS 1039, Springer Verlag, 1996, pp.205-218 -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.suginami.tokyo.jp URL://www.pp.iij4u.or.jp/~h2np Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA05301 for ietf-open-pgp-bks; Tue, 20 Jan 1998 10:27:30 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA05284 for ; Tue, 20 Jan 1998 10:27:22 -0800 (PST) Received: from s20.term1.sb.rain.org (s26.term2.sb.rain.org [198.68.144.186]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id KAA08658; Tue, 20 Jan 1998 10:31:33 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id KAA10135; Tue, 20 Jan 1998 10:16:19 -0800 Date: Tue, 20 Jan 1998 10:16:19 -0800 From: Hal Finney Message-Id: <199801201816.KAA10135@s20.term1.sb.rain.org> To: hironobu@h2np.suginami.tokyo.jp, whgiii@invweb.net Subject: Re: OpenPGP WG meeting minutes Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk William H. Geiger III, , writes: > Anyone unfamiliar with Misty should look at the CP archives for the > numerous posts by Nobuki Nakatuji. It has snake-oil written all over it. > This is exactly what is meant by 'pet' algorithm. Misty is described in the proceedings of the most recent annual conference on fast encryption algorithms. It is designed to be provably resistant to linear and differential cryptanalysis. As a new set of algorithms (a few variants exist under the "Misty" label), it is one of many where a "wait and see" attitude is appropriate to see how it holds up. As a patented algorithm, it may have trouble competing with alternatives that are free of restrictions. However your charge that it is "snake-oil" seems unfounded. It appears to be a respectable academic development effort, within the mainstream of cryptographic research, and has some reasonable-looking theory behind it. As far as I know there has been no cryptanalysis or technical commentary of any sort regarding Misty on the cypherpunks mailing list. Hal Finney hal@pgp.com hal@rain.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA03636 for ietf-open-pgp-bks; Tue, 20 Jan 1998 09:35:00 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA03621 for ; Tue, 20 Jan 1998 09:34:53 -0800 (PST) Received: from whgiii (cppp31.dotstar.net [208.143.93.131]) by users.invweb.net (8.8.7/8.8.7) with SMTP id MAA10398; Tue, 20 Jan 1998 12:55:11 -0500 Message-Id: <199801201755.MAA10398@users.invweb.net> From: "William H. Geiger III" Date: Tue, 20 Jan 98 11:32:57 -0500 To: Hironobu Suzuki In-Reply-To: <9801201448.AA20368@h2np.suginami.tokyo.jp> Cc: ulf@fitug.de (Ulf =?iso-8859-1?Q?M=F6ller), ietf-open-pgp@imc.org?= Subject: Re: OpenPGP WG meeting minutes X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <9801201448.AA20368@h2np.suginami.tokyo.jp>, on 01/20/98 at 09:48 AM, Hironobu Suzuki said: >>>>>> "Ulf" == Ulf =?iso-8859-1?Q?M=F6ller?= writes: > >> But I want new algorithm id for MISTY1 when this document become > >> RFCXXXX. MISTY1 which was designed by Matsui-san looks so good. I > >> believe an algorithm which is described in RFC is not a `pet' one. > Ulf> This algorithm is not any useful in the context of OpenPGP > Ulf> because it is patented and is freely available only for academic > Ulf> use. >That's right. >I realize that "FREELY AVAILABLE ONLY FOR ACADEMIC" is the biggest >obstacle to become MISTY1 draft to RFC. I think ( and hope ) when MISTY1 >draft goes to RFC, MISTY1 will be royalty-free algorithm as well as >CAST128. If MISTY1 can't become royalty-free, MISTY1 draft maybe reject. Anyone unfamiliar with Misty should look at the CP archives for the numerous posts by Nobuki Nakatuji. It has snake-oil written all over it. This is exactly what is meant by 'pet' algorithm. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- Tag-O-Matic: Windows is to OS/2 what Etch-a-Sketch is to art. -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNMTTQI9Co1n+aLhhAQECAgP/QN9k2AvjPRgTEJeDLz9B2YiqF/l99MMK pnffUnPLM2Zb8vp0zSEu+YiNLWyeLJ9yHB3F1W85xFQbPzTxyb2Xt+HFiW/FLJTP EcrRT4WRaMYfSy+n1RPPM9dpiIptwmXLjTpPtpAioS7T7UXmylID1KLfAvTT4kR7 jsgb9kBCyoE= =h2+U -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA02132 for ietf-open-pgp-bks; Tue, 20 Jan 1998 06:56:55 -0800 (PST) Received: from mail0.iij.ad.jp (mail0.iij.ad.jp [202.232.2.113]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA02127 for ; Tue, 20 Jan 1998 06:56:51 -0800 (PST) Received: from uucp1.iij.ad.jp (uucp1.iij.ad.jp [202.232.2.201]) by mail0.iij.ad.jp (8.8.8/3.6W-MAIL) with SMTP id AAA12597; Wed, 21 Jan 1998 00:01:20 +0900 (JST) Received: (from uucp@localhost) by uucp1.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id AAA08557; Wed, 21 Jan 1998 00:01:23 +0900 Received: from localhost by h2np.suginami.tokyo.jp (NX5.67c/IIJ-U1.2c) id AA20368; Tue, 20 Jan 98 23:48:49 +0900 Message-Id: <9801201448.AA20368@h2np.suginami.tokyo.jp> To: ulf@fitug.de (Ulf =?iso-8859-1?Q?M=F6ller?=) Cc: ietf-open-pgp@imc.org Subject: Re: OpenPGP WG meeting minutes In-Reply-To: Your message of "Tue, 20 Jan 1998 14:05:14 +0100." <9801201305.AA58140@public.uni-hamburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 Jan 1998 23:48:48 +0900 From: Hironobu Suzuki Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >>>>> "Ulf" == Ulf =?iso-8859-1?Q?M=F6ller?= writes: >> But I want new algorithm id for MISTY1 when this document become >> RFCXXXX. MISTY1 which was designed by Matsui-san looks so good. I >> believe an algorithm which is described in RFC is not a `pet' one. Ulf> This algorithm is not any useful in the context of OpenPGP Ulf> because it is patented and is freely available only for academic Ulf> use. That's right. I realize that "FREELY AVAILABLE ONLY FOR ACADEMIC" is the biggest obstacle to become MISTY1 draft to RFC. I think ( and hope ) when MISTY1 draft goes to RFC, MISTY1 will be royalty-free algorithm as well as CAST128. If MISTY1 can't become royalty-free, MISTY1 draft maybe reject. --hironobu PS. I already e-mailed to Matsui-san and Ohta-san about algorithms in RFC should be free from royalty. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA01622 for ietf-open-pgp-bks; Tue, 20 Jan 1998 05:01:18 -0800 (PST) Received: from public.uni-hamburg.de (public.uni-hamburg.de [134.100.41.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id FAA01611 for ; Tue, 20 Jan 1998 05:00:51 -0800 (PST) Received: by public.uni-hamburg.de (AIX 4.1/UCB 5.64/4.03) id AA58140; Tue, 20 Jan 1998 14:05:14 +0100 Message-Id: <9801201305.AA58140@public.uni-hamburg.de> Subject: Re: OpenPGP WG meeting minutes To: hironobu@h2np.suginami.tokyo.jp (Hironobu Suzuki) Date: Tue, 20 Jan 1998 14:05:14 +0100 (NFT) Cc: ietf-open-pgp@imc.org In-Reply-To: <9801200250.AA18842@h2np.suginami.tokyo.jp> from "Hironobu Suzuki" at Jan 20, 98 11:50:17 am From: ulf@fitug.de (Ulf =?iso-8859-1?Q?M=F6ller?=) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > But I want new algorithm id for MISTY1 when this document become > RFCXXXX. MISTY1 which was designed by Matsui-san looks so good. I > believe an algorithm which is described in RFC is not a `pet' one. This algorithm is not any useful in the context of OpenPGP because it is patented and is freely available only for academic use. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA21847 for ietf-open-pgp-bks; Mon, 19 Jan 1998 19:17:15 -0800 (PST) Received: from mail0.iij.ad.jp (mail0.iij.ad.jp [202.232.2.113]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA21843 for ; Mon, 19 Jan 1998 19:17:10 -0800 (PST) Received: from uucp1.iij.ad.jp (uucp1.iij.ad.jp [202.232.2.201]) by mail0.iij.ad.jp (8.8.8/3.6W-MAIL) with SMTP id MAA18347 for ; Tue, 20 Jan 1998 12:21:43 +0900 (JST) Received: (from uucp@localhost) by uucp1.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id MAA28882 for ietf-open-pgp@imc.org; Tue, 20 Jan 1998 12:21:47 +0900 Received: from localhost by h2np.suginami.tokyo.jp (NX5.67c/IIJ-U1.2c) id AA18842; Tue, 20 Jan 98 11:50:18 +0900 Message-Id: <9801200250.AA18842@h2np.suginami.tokyo.jp> To: ietf-open-pgp@imc.org Subject: Re: OpenPGP WG meeting minutes In-Reply-To: Your message of "Mon, 19 Jan 1998 13:03:38 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 Jan 1998 11:50:17 +0900 From: Hironobu Suzuki Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > Miscellaneous: (Comments not recorded) ... > We should not just put in everyone's pet algorithms. I agree. But I want new algorithm id for MISTY1 when this document become RFCXXXX. MISTY1 which was designed by Matsui-san looks so good. I believe an algorithm which is described in RFC is not a `pet' one. ----MISTY1 INTERNET DRAFT---- INTERNET-DRAFT H. Ohta Expires in six months M. Matsui Mitsubishi Electric Corporation December 1997 A Description of the MISTY1 Encryption Algorithm --- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.suginami.tokyo.jp URL://www.pp.iij4u.or.jp/~h2np Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA07637 for ietf-open-pgp-bks; Mon, 19 Jan 1998 14:33:34 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id OAA07633 for ; Mon, 19 Jan 1998 14:33:29 -0800 (PST) Message-Id: <199801192233.OAA07633@mail.proper.com> Received: (qmail 24687 invoked from network); 19 Jan 1998 22:37:59 -0000 Received: from ts3416.powerup.com.au (HELO lindsay) (203.32.9.144) by enterprise.powerup.com.au with SMTP; 19 Jan 1998 22:37:59 -0000 Date: 20 Jan 1998 23:25:57 GMT From: Lindsay Mathieson Subject: Re: OpenPGP WG meeting minutes To: "John W. Noerenberg" , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.8 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >o Develop a protocol based on RFC 1873, RFC 2015 and PGP to > encrypt and sign email. Do you mean RFC 1847 rather than 1873 ? -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.8, on January 20, 1998, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA01462 for ietf-open-pgp-bks; Mon, 19 Jan 1998 13:13:04 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA01440 for ; Mon, 19 Jan 1998 13:12:57 -0800 (PST) Received: from [129.46.137.43] (servo.qualcomm.com [129.46.101.170]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id NAA18371; Mon, 19 Jan 1998 13:16:10 -0800 (PST) X-Sender: jwn2@127.0.0.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 4.0.1a2-2.98] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Mon, 19 Jan 1998 13:03:38 -0800 To: minutes@ietf.org, OpenPGP mailing list From: "John W. Noerenberg" Subject: OpenPGP WG meeting minutes Cc: Tony Mione Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Here are the long delayed minutes from the IETF meeting in December. Tony Mione recorded them, and I've annotated them slightly. 40th IETF, Washington, DC OpenPGP Working Group Meeting Minutes 8-Dec-1997 Antonino N. Mione John Norenberg made openning comments and reviewed the agenda for the meeting. OpenPGP Meeting Agenda WG Goals (John Norenberg) Phil Zimmerman (Comments) Draft : PGP Message formats (Jon Callas) 2015 OP/MIME Trust model documents (John Norenberg) Additional topics or other business? WG Goals (John Norenberg) John read the Working Group Charter in order to review the goals of the group. John's comments: The goal of the OpenPGP group is to do two things. o Develop a cryptographic exchange protocol based on PGP packets. o Develop a protocol based on RFC 1873, RFC 2015 and PGP to encrypt and sign email. Phil Zimmerman (Comments) Phil Zimmerman was asked to make comments on PGP and the IETF working group. Phil's comments mainly revolved around his original design goals. He has resisted throwing in just "any" proposed block cipher. He is also trying to preserve the "Grass roots" architecture of the original PGP implementation. Question from WG attendee: Has X.509 compatibility been considered? Phil: I would like to avoid it. It is bloated & expensive to implement. However, we would like to peacefully coexist with this technology and provide users an upgrade path from X.509 to OpenPGP. Question from WG attendee: Did you mean this for the OpenPGP standard or just for PGP Inc.? Phil: That is up to this Working group Question from WG attendee: Are you also designing a PKI and SPKI? John N.: We are dnt defining an infrastructure. Just how keys work. There will have to be continual heavy pressure from outside the working group in order for us to take that on. John N(Additional comments): A 'standard' must be well defined and widely deployed in order to be useful. Our goal is to have a standard for cryptographic message exchange. Draft : PGP Message formats (Jon Callas) Jon discussed the most recent decisions on various open issues in the PGP Message formats draft (drafts-ietf-openpgp-formats-00.txt). There was some discussion on certain points. Some decisions by Jon, et al were reversed or modified during the discussion. 2.4 Armor - This needs to be moved to a separate chapter. Chapter 2 will say that implementations SHOULD support ARMOR. Armor headers - We need to have a table of these. We also need to flesh out generation of the message ids for multi-part messages. 2.6 Cleartext signatures - We are removing this x.x Counted strings - This will be removed. The type is not used except for one or two places. We will define it in those places and declare it as a simple type. 2.5.3.3 Iterated/Salted String-to-key - This is long, hairy and complicated to implement. We have considered removing it. The rationale for its use is that: 1-Salt perturbs encryption of strings (same string encrypts to different values each time it is used) 2-Iteration adds compute time for the craker program running a dictionary attack. We've seen 3 options mentioned 1) Remove it 2) Change 8-bit float to 32 bit int 3) Change it to a MAY Request for comments from WG Comments from WG member: Options add complexity but is useful and important. The member would not have a problem with it if the float was changed to a 32-bit integer (2). 4.2 Encrypted Session Key - Will be changing the name of this to Public Encrypted Session Key to balance naming with Conventionally Encrypted Session Key. 5.3 Signatures These will be put in a table and marked as required or optional as per comments on the mailing list. ISSUER ID subpacket - This will be added to hashed subpackets ARR subpacket - This will be defined as optional. The draft will say explicitly that the implementation can do anything it wants with this. It does not have to use it. Comments from WG attendee: Agrees with consensus. However, would like words to tell implementors what to do if they do not want to handle it. Jon Callas response: Sounds good. Critical flag: This section is confusing. Will rewrite to say that if the critical subpacket is not understood by the implementation, the signature must be ignored. Comment from WG attendee: Criticality must be MUST. This means if the implementation does not understand the critical subpacket type, it must consider the signature invalid. Phil: Disagrees. The signature is still valid and should be considered such. However, use of any semantic meaning of the signature is lost. Preferred key server: Good to have a place to get most recent key. Comments from WG attendee: This is starting us down a slippery slope. John Norenberg: Yes, we have to be careful. But if we stick to defining how to represent keys, and leave the protocols for infrastructure to the infrastrucute folks, we'll be ok. Phil: This is good but we need more experience with protocols i.e. an implementation that does this. Regular expressions: We need a syntax for regular expressions sub packet. Requested pointers to a description of a reg exp library to which the draft can refer. Negative preferences? (Editor's question) : Did not recieve comments saying this was needed. As a result, we will not proceed with this. UserId revocation subpackets: These will be deferred to v2. Other subpacket types (Editor's notes) : Jon had noted some packet types that were described (or reserved) in an earlier PGP implementation. These were never actually implemented. The question was, should we do any of them. Since nobody responded that they could not live without these features, they will be deferred. 5.2.2. Signature types Identifity : Generic,Personal,Casual,Positive Other than Generic, no implementation has generated or handled these. As a result there is no history or experience on what the symantics should be. Personal, Casual, and Positive will be dropped from the document. Timestamp signatures We shouldn't be taking this on. This is another Slippery Slope. We will, however, note that they exist. Signatures that bind keys with subkeys We have not received a good definition of this. If we don't get a solid definition, we will leave this out. Secret keys Encryption is done in PGP's variant of CFB. (Other comments not recorded). Marker packet We will change text so that an implementation can put anything it wants into this packet. We will also suggest it should contain the impelmentor's name. Trust packets These will explicitly mark them as implementation-defined. Comments from Jeff Shiller(back to marker packet) : Can't this be used to leak out data (like the clear text message xor'ed with something)? Why have this at all. It is a security risk. Discussion followed. Jon Callas: We will state that it MUST be a constant to avoid it being exploited to subvert security. Non-text UserIds : These will be deferred. They are not yet defined well enough. Comments from Phil: These are going to be important. We need this in the spec now. Discussion followed concerning formatting problems, etc. Jon Callas (to Phil): Send a specification to the openpgp list. SDSI names : These will be deferred. Jon Callas : These are a good thing but we do not have enough time. Additional comments from Jon: This draft is supposed to go to last call sometime in March 98. Ideally, we will be AHEAD of that schedule. Jon is hoping to have a new draft up shortly, handle additional comments over then next month or so (through January) and go to last call in February of 98. Comment packets : An implementation MAY display a comment but MUST NOT interpret contents. Jeff Shiller: You may want to reconsider using UTF-8 for textbased userid's. Jon Callas: This has already been specified in the draft (at least, he is pretty sure of this.) Chris : Recommends that comments be removed altogether. Jeff Shiller: agrees with this. Jon Callas: Fine. We will remove them. 5.n: Interoperability packets: These are desireable, but deferred. The existing definitions are insufficient. Subkeys (Comments unrecorded) 7.2 BNF : We need additional BNF for how signatures are formed. Comments from WG attendee: Please include at least one example. Seconded... Jon Callas: Noted... Security considerations: We will be adding description of stealth-mode and packet analysis avoidance. Miscellaneous: (Comments not recorded) Comments on alogrithm lists from Phil: We have multiple algoritms to ensure that if one breaks, users can contine operating securly by just changing preferences. We should, however, shoot for minimal # of algoritms. We should not just put in everyone's pet algorithms. Comment from WG attendee: Other specs give one MUST and everything else MAY. Market should drive the algorithm selection. We should not limit it. Phil: Maintained that WE should pick the algorithms. Attitude is: "I know cryptography, you don't." Perry Metzger: Pick minimum # and types of algoritms for interoperability. Let market drive rest. Chris?: We should provide a 'private algorithm #' with no content description. This allows others to use OIDs, etc to implement anything they want. Ned: Agreed. Also, this is not the time to add tons of algorithms to the spec. Jon Callas : This is already done. 11 things are reserved for private algorithms. Algorithms: Blowfish GOST, needs sboxes specified Jon Callas: I can't specify these. AES : We have reserved an id Ellyptic Curve, IDEA-EDE - added. Speculative (stealth mode) keyIDs - Cut's traffic analysis. We need to write rationale sections 2015 OP/MIME Draft Status Technical Changes Draft status: 80% complete www.imc.org/ietf-pgp-mime/mail-archive/0081.html New Draft will be in: www.imc.org/ietf-open-pgpg/draft-ietf-opengpg-mime-00.txt Draft has been submitted to IETF. Technical changes: OP Msg formats now have details New MIME constant types have been defined - application/openpgp-encrypted - application/openpgp-signature Quick vote: Do we want these defined? : 4 against : 10+ for 2xx abstentions? Content transfer encoding restrictions - generate strictly, accept liberally OpenPGP encrypted data Question : MIME or OP encryption first? Decision : MIME cannonicalized first, then encrypted OpenPGP signed data - protocol = application/openpgp-signature = openpgp-md5 openpgp-sha1 openpgp-ripemd160 openpgp-haval (15 variants) Parallel signatures are popular RFC1847 based parallel signatures on the same data have been defined. Distribution of PGP keys This text will be moved to PGP certificate document. Ned Freed: Ongoing issue with multipart signed messages. The issues concern gateways. He encouraged people to read and comment on his draft concerning this: drafts-freed-gsec-00.txt. Trust model documents (John Norenberg) There are numerous types of trust models. It would probably be good to have a document on this. The document would cover: - What trust models are available. - How they work. - How they are implemented in the context of PGP. Question for group: Do we need this? Paul Hoffman: Agrees. Would be good to have a separate document on this. John Norenberg : Should we vote here or defer this question to the list? Rodney: Let's take these questions to the list and decide there. Any other business? Blue sheet...all signed? about 40 not yet on list. John Norenberg summarized what was covered at the meeting. He then closed the meeting at 3:10 PM (20 minutes ahead of schedule). john w noerenberg, ii jwn2@qualcomm.com ------------------------------------------------------------------ "YOU THINK THEY GIVE YOU THE SHIVERS NOW," Owen said. "JUST WAIT UNTIL HE STARTS MAKING DECISIONS!" -- John Irving, A Prayer for Owen Meany, 1989 ------------------------------------------------------------------ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA18413 for ietf-open-pgp-bks; Thu, 15 Jan 1998 14:22:54 -0800 (PST) Received: from ccimail.mediaone.com (ccimail.mediaone.com [169.152.79.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA18409 for ; Thu, 15 Jan 1998 14:22:50 -0800 (PST) From: Il207y3z3@bri1eflyheavy.com Received: from kWHv94tGl (1Cust64.tnt26.atl2.da.uu.net [208.255.221.64]) by ccimail.mediaone.com (8.8.7/8.8.7) with SMTP id QAA12970; Thu, 15 Jan 1998 16:09:56 -0500 (EST) DATE: 14 Jan 98 4:15:58 PM Message-ID: TO: tell@alltheworld35.com SUBJECT: CyberNews Sender: owner-ietf-open-pgp@imc.org Precedence: bulk LET US DO YOUR BULK MAILINGS!!! ..$350 PER MILLION ADDRESSES SENT ..$250 PER 1/2 MILLION ADDRESSES SENT THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS! Our company will do bulk emailing for your product/service. Addresses are extracted daily by six of our computers, which run 24 hours a day 7 days a week, scanning the net for new addresses. Estimated 60-80,000 addresses extracted daily. They are fresh! Over 40 million addresses on file. No more than 2 pages (50 lines), no porn and no foul language. $50 per page/25 lines per page beyond 2 pages. We do not do targeted mailings at this price. Targeted mailings: $150 per 50,000 addresses extracted or less. We can extract by country, occupation, organizations, associations, product, etc. If we can not search and extract what you need, then nobody can. There are no lower prices on the net. Your mailing can be done in a matter of hours. We have 6 computers extracting addresses 24/7. For the fastest service, cheapest prices and cleanest mailings call our processing and new accounts office at 904-282-0945, Monday - Friday 9 - 5 EST. If the line is busy, please keep trying, as bulk mailing is growing fast. We do want to work with you to advertise your product. To have your name removed, call our processing office. Any negative responses will be dealt with accordingly. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA24562 for ietf-open-pgp-bks; Wed, 14 Jan 1998 11:23:44 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA24543 for ; Wed, 14 Jan 1998 11:23:30 -0800 (PST) Received: from MYHOSTNAME (cppp33.dotstar.net [208.143.93.133]) by users.invweb.net (8.8.7/8.8.7) with SMTP id OAA04996; Wed, 14 Jan 1998 14:39:19 -0500 Message-Id: <199801141939.OAA04996@users.invweb.net> From: "William H. Geiger III" Date: Wed, 14 Jan 98 13:26:17 -0500 To: pgp-users@joshua.rivertown.net Cc: ietf-open-pgp@imc.org, pgp-dev@pgpi.com Subject: Lost Messages X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hi, In the process of switching to a new sever I have lost several days worth of mail. If you have directly messaged me in the past couple of days please resend. Thanks, - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- Tag-O-Matic: Air conditioned environment - Do not open Windows. -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNL0DFo9Co1n+aLhhAQFmAQQAyH0ix6H2GAihTTqP15rOh2271eqAawjB JtM/idmd0iMJxBqxplBcn9ODc7LJs7FJ7iMMREnx8J3oSi/bCh4YloEZ0kqqkIW+ +s5WnMPvWP9UjzQjQZ5Emy0uAEXWknAtIWc+e58gnSjxB+b3ue3GB4mw4c6RdhwN s5mtihRWNg0= =Rml5 -----END PGP SIGNATURE----- Tag-O-Matic: I'm an OS/2 developer...I don't NEED a life! Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA27607 for ietf-open-pgp-bks; Fri, 9 Jan 1998 07:28:27 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA27600 for ; Fri, 9 Jan 1998 07:28:23 -0800 (PST) Received: from s20.term1.sb.rain.org (s26.term2.sb.rain.org [198.68.144.186]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id HAA03781; Fri, 9 Jan 1998 07:32:16 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id HAA04220; Fri, 9 Jan 1998 07:16:35 -0800 Date: Fri, 9 Jan 1998 07:16:35 -0800 From: Hal Finney Message-Id: <199801091516.HAA04220@s20.term1.sb.rain.org> To: bromage@cs.mu.oz.au, stewarts@ix.netcom.com Subject: Re: Speculative Mode for KeyIDs of all zeroes Cc: iang@systemics.com, ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Colin Plumb has an amusing quote in the bignum library, where another algorithm is used that has a failure probability: "The chances that another Dinosaur Killer asteroid will land today is about 10^-11 or 2^-36, so it would be better to spend your time worrying about *that*." This is assuming that such asteroids hit Earth every billion years or so. It also assumes that they aren't detectable in advance, which according to a documentary I saw recently about the late Dr. Gene Shoemaker, is correct. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA13004 for ietf-open-pgp-bks; Fri, 9 Jan 1998 01:30:42 -0800 (PST) Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by mail.proper.com (8.8.7/8.7.3) with SMTP id BAA12995 for ; Fri, 9 Jan 1998 01:30:36 -0800 (PST) Received: from mundook.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.51) id AA03747; Fri, 9 Jan 1998 20:34:33 +1100 (from bromage@mundook.cs.mu.OZ.AU) Received: (from bromage@localhost) by mundook.cs.mu.OZ.AU (8.8.5/8.7.3) id UAA18629; Fri, 9 Jan 1998 20:34:27 +1100 (EST) From: Andrew Bromage Message-Id: <199801090934.UAA18629@mundook.cs.mu.OZ.AU> Subject: Re: Speculative Mode for KeyIDs of all zeroes To: stewarts@ix.netcom.com (Bill Stewart) Date: Fri, 9 Jan 1998 20:34:26 +1100 (EST) Cc: iang@systemics.com, ietf-open-pgp@imc.org In-Reply-To: <3.0.3.32.19971207181613.02f65430@popd.ix.netcom.com> from Bill Stewart at "Dec 7, 97 06:16:13 pm" X-Mailer: ELM [version 2.4ME+ PL15 (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 -----BEGIN PGP SIGNED MESSAGE----- G'day all. Bill Stewart wrote: > The probability of a generating a key with KeyID of 0 is 2**-64. > It could happen by accident, though it probably won't, and worst case is > the lucky user of such a key will just have to check all messages > sent to him that have KeyID 0 against all his keys. > Annoying, but no loss of functionality. Is it so hard for a key generator to guarantee that it never produces a 64 bit key of ID 0? Generate another, or massage the original key in a random way. If you amortise the cost over all decryptions to be performed with that key, it probably turns out to be cheaper. Cheers, Andrew Bromage -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNLXvFBF7J5ORR6ohAQFyfAP/WN9g/g4Lq9CIjfC2r5MDU1SvdiQpYwjl XF4yuBiL+4i31EXBe08XRlfD/vWNyRInRqhA9yNE9AJz8mTX4p7dyVcoLa9y9ZTZ tQTOsEoc0BfA8MXktRQGs5KBZtbv1jOF9bq8NmYrVDNKm70sb5f+4YtyUWzy7Azk lqBc89sdoFc= =Ya1r -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA18558 for ietf-open-pgp-bks; Wed, 7 Jan 1998 22:35:51 -0800 (PST) Received: from bi-node.foebud.org (root@bi-node.foebud.org [194.77.23.10]) by mail.proper.com (8.8.7/8.7.3) with SMTP id WAA18554 for ; Wed, 7 Jan 1998 22:35:46 -0800 (PST) Received: from bionic.zerberus.de with zconnect by bi-node.foebud.org with zconnect (/\oo/\ Smail3.1.29.1 #29.1 #1) id m0xq8hN-003e4mC; Thu, 8 Jan 98 04:32 MET Received: from localhost by nescio.zerberus.de with smtp (Smail3.1.29.1 #7) id m0xjLHI-000FSVC; Sat, 20 Dec 97 10:33 MET To: David Sternlight CC: ietf-open-pgp@imc.org Message-Id: From: christopher@nescio.foebud.org (Christopher Creutzig) Path: bionic.zerberus.de!nescio.foebud.org!christopher Subject: Re: The web of trust has no clothes. Date: Sat, 20 Dec 1997 10:32:58 +0100 (MET) References: <347A293B.394BFE6C@sternlight.com> X-Gateway: ZCONNECT bi-node.foebud.org [UNIX/Connect v0.75b4], RFC1036/822 nescio.zerberus.de [UNIX/Connect v0.75b4/19970818] X-ZC-KOP: ietf-open-pgp@imc.org Lines: 25 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Mon, 24 Nov 1997, David Sternlight wrote: -> not only does everyone with an old RSA key have to generate a new key -> but also a complete new set of signatures and web of trust must be built -> if they wish to use the "better" algorithms. And the new keys must be That's easy: - Generate your new key. - Sign it with your old key, possibly send it clear-signed or whatever. - Send it to the persons who signed your old key. They can verify your signature on the new key and since they checked you're the one with the old key, they can validly assume you signed the new one allright. - After this verification, they can sign the new key and send it back. - In the unlikely event that someone got hold of your secret key, they can simply revoke their sgnatures. It's really unlikely, however. -- Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873 # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # "Das kann doch nicht so schwer sein, so ein paar Header zu erzeugen!" (Eike Rathke auf der Gatebau'97) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA14604 for ietf-open-pgp-bks; Wed, 7 Jan 1998 16:30:47 -0800 (PST) Received: from newmail.virgin.net ([194.168.54.44]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA14600 for ; Wed, 7 Jan 1998 16:30:42 -0800 (PST) Received: from server.eternity.org ([194.168.56.166]) by newmail.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 549-33929U100000L2S50) with ESMTP id AAF14508; Thu, 8 Jan 1998 00:34:35 +0000 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id AAA00700; Thu, 8 Jan 1998 00:22:15 GMT Date: Thu, 8 Jan 1998 00:22:15 GMT Message-Id: <199801080022.AAA00700@server.eternity.org> From: Adam Back To: platypus@acmeonline.net CC: ietf-open-pgp@imc.org In-reply-to: (message from ? the Platypus {aka David Formosa} on Wed, 7 Jan 1998 10:20:18 +1100 (EST)) Subject: Re: message integrity checksum? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk David Formosa writes: > On Tue, 6 Jan 1998, Adam Back wrote: > > > Gary Howland discussed PGP vulnerabilities at HIP97 I think. One of > > the vulnerabilities was that encrypted (but not signed) messages could > > be altered undetectably. > > This vulnerability is commen to any system that is encrypted but not > signed. Not necessarily, it just depends if this property has been designed into the protocol design. For example SSLv3 has cipher suite ADH-DES-CBC3-SHA -- this cipher suite is not signed -- it is symmetrically encrypted with 3DES, but it also has an HMAC based authentication code with keying material derived from session data. It is vulnerable to MITM, however because there is no authentication at all. Many systems are based on symmetric key technology only, where shared-key authentication mechanisms are used. This is why I asked "is this considered a problem?" It could be a problem if people assume this property. I think it would be a useful property to add. Either add, or note lack of this property as a security warning. I have some vague recollection that PGP said shortly after Gary gave his talk that they had addressed the security problem(s) that Gary raised. It would appear that the modifiable unsigned bulk encrypted data has not been fixed unless I missed this in the currrent draft. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Tue, 6 Jan 1998 23:11:44 -0800 (PST) Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id BAA22424; Wed, 7 Jan 1998 01:13:48 -0600 (CST) Received: from pax-ca14-16.ix.netcom.com(204.31.233.80) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma022208; Wed Jan 7 01:11:49 1998 Message-Id: <3.0.5.32.19980106220827.00851eb0@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 06 Jan 1998 22:08:27 -0800 To: Adam Back , hal@rain.org From: Bill Stewart Subject: Re: OpenPGP IETF meeting -- what happened? (Re: section 4.3) Cc: ietf-open-pgp@imc.org In-Reply-To: <199712312240.WAA00437@server.eternity.org> References: <199712311642.IAA05720@s20.term1.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 10:40 PM 12/31/1997 GMT, Adam Back wrote: >> This is a good explanation. Thanks for providing it. There has been so >> much attention paid to the additional recipient feature that few people have >> had the energy to look at the other new features. > >What happened to the ARR anyway? Is it still there? What happened at >IETF? I don't know about the IETF meeting discussion of it, but the ARR (etc.) is Yet Another Subpacket Type, and therefore has a known size and can be skipped over if it's not implemented. So if we don't document it and don't talk about it, everything works, or if we document the subpacket type number as "Reserved For Evil Eavesdroppers", everything still works. Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA23903 for ietf-open-pgp-bks; Tue, 6 Jan 1998 16:42:48 -0800 (PST) Received: from lancelot.st.nepean.uws.edu.au (lancelot.st.nepean.uws.edu.au [137.154.148.30]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA23891 for ; Tue, 6 Jan 1998 16:42:42 -0800 (PST) Received: from oberon.st.nepean.uws.edu.au (oberon [137.154.148.13]) by lancelot.st.nepean.uws.edu.au (8.8.5/8.8.5) with ESMTP id LAA01655; Wed, 7 Jan 1998 11:46:12 +1100 Received: from shirley (dformosa@dialin-29 [137.154.130.29]) by oberon.st.nepean.uws.edu.au (8.8.5/8.8.5) with SMTP id LAA19440; Wed, 7 Jan 1998 11:46:10 +1100 (EST) Date: Wed, 7 Jan 1998 10:20:18 +1100 (EST) From: ? the Platypus {aka David Formosa} X-Sender: dformosa@shirley Reply-To: platypus@acmeonline.net To: Adam Back cc: ietf-open-pgp@imc.org Subject: Re: message integrity checksum? In-Reply-To: <199801061831.SAA00377@server.eternity.org> Message-ID: x-url: http://www.st.nepean.uws.edu.au/~dformosa/Spelling.html MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Tue, 6 Jan 1998, Adam Back wrote: > Gary Howland discussed PGP vulnerabilities at HIP97 I think. One of > the vulnerabilities was that encrypted (but not signed) messages could > be altered undetectably. This vulnerability is commen to any system that is encrypted but not signed. It is not a perculartity of PGP. > Clearly one way to fix it is to use signatures. Of cause. - -- Please excuse my spelling as I suffer from agraphia see the url in my header. Never trust a country with more peaple then sheep. ex-net.scum and proud You Say To People "Throw Off Your Chains" And They Make New Chains For Themselves? --Terry Pratchett. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNLK8OaQK0ynCmdStAQEjaAP/ZD1wWYJ5+gQYNitZEjLI3SaVdGYHEecz UG8BZFPB7vsbZY4ZrPq9KTwdIGIf5ExNQwfh6piR77JbYJLMYcRZsdZM2V4t2neh kne/3Db3RGzdsjM4RSykrGfsPcM2EPhOub/5/0YgDCPn7ot54KB0n9mai6+r3QoL dTzb0tcpynU= =j9J6 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA22229 for ietf-open-pgp-bks; Tue, 6 Jan 1998 14:37:45 -0800 (PST) Received: from newmail.virgin.net ([194.168.54.44]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA22223 for ; Tue, 6 Jan 1998 14:37:40 -0800 (PST) Received: from server.eternity.org ([194.168.72.157]) by newmail.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 549-33929U100000L2S50) with ESMTP id AAB8071; Tue, 6 Jan 1998 22:41:22 +0000 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id WAA00191; Tue, 6 Jan 1998 22:38:07 GMT Date: Tue, 6 Jan 1998 22:38:07 GMT Message-Id: <199801062238.WAA00191@server.eternity.org> From: Adam Back To: gary@hotlava.com CC: ietf-open-pgp@imc.org, ianb@acm.org In-reply-to: <199801062137.VAA20053@hermes> (message from Gary Howland on Tue, 06 Jan 1998 22:38:01 +0100) Subject: Re: message integrity checksum? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Gary Howland writes: > Adam Back wrote: > > [lack of integrity check in PGP bulk symmetric encryption] > > > > I think the example given is that someone might use this (symmetric > > encryption) to send commands to a remote command executer which would > > be trusted because it was encrypted with a shared passphrase. This > > shows that the last command say could be garbled, resulting in a null > > operation and potential security problem. > > With known plaintext, the last 8 bytes can be set to anything the attacker > desires - so it's not just a case of removing or randomly corrupting data. Indeed. Worse than that even -- you can modify arbitrary blocks, and because of the way ciphertext error propagation works in 64 bit (ie in cipher block size feedback) CFB mode only the following block will be garbled, further blocks will recover. The last block can be altered without any garbling at all because there is no following block. > You can find the paper for the talk at: > > http://www.hotlava.com/doc/index.html Perhaps you covered the above, as I hadn't read your paper; will read. Of course the attack is harder if one must cope with compression -- when we discussed this before you considered it possible to do even with compression -- I tend to agree, though it will limit your flexibility in that you will likely have to limit yourself to last block attacks otherwise the following garbled block will likely corrupt the compression, plus you will be limited to matching the compression message bit length which is stored inside the encryption envelope. (I am presuming compression is not necessarily a mulitple of 8 bits long -- this assumption could be wrong, as I am not familiar with ZIP algorithm, this assumption is based on huffman encoding). Ciphertext error recovery properties have interesting implications for protocol modifications to add message integrity protection -- for instance appending a MD5 digest of the message to the plaintext prior to encryption would not solve the problem. I think a keyed MAC such as HMAC would do the trick with the MAC key and the MAC output both being inside the encryption envelope. You would want to check that MAC key and ouput position alignment and padding in the modified protocol do not weaken the brute force resistance to modification provided by the MAC key size. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA21518 for ietf-open-pgp-bks; Tue, 6 Jan 1998 13:34:12 -0800 (PST) Received: from hotlava.com (internal-mail.hotlava.com [193.67.124.74]) by mail.proper.com (8.8.7/8.7.3) with SMTP id NAA21511 for ; Tue, 6 Jan 1998 13:34:07 -0800 (PST) Message-Id: <199801062134.NAA21511@mail.proper.com> Received: (qmail 1496 invoked from network); 6 Jan 1998 21:38:01 -0000 Received: from localhost (@127.0.0.1) by localhost with SMTP; 6 Jan 1998 21:38:01 -0000 X-Mailer: exmh version 2.0gamma 1/27/96 To: Adam Back cc: ietf-open-pgp@imc.org, ianb@acm.org Subject: Re: message integrity checksum? In-reply-to: Your message of "Tue, 06 Jan 1998 18:31:21 GMT." <199801061831.SAA00377@server.eternity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jan 1998 22:38:01 +0100 From: Gary Howland Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > > Gary Howland discussed PGP vulnerabilities at HIP97 I think. One of > the vulnerabilities was that encrypted (but not signed) messages could > be altered undetectably. > > This can be demonstrated (with pgp2.6 command line): > > % echo hello world > junk > % pgp -c +compress=off -zfred junk > % sed 's/....$/adam/' < junk.pgp > junk2.pgp > % pgp -zfred junk2.pgp > % cat junk2 > hello woP?t > > (pgp doesn't complain or even notice the above ... there is no > checksum and so you can just garble the file, if you so wish, and pgp > won't complain). > > Was this viewed as a problem? > > I think the example given is that someone might use this (symmetric > encryption) to send commands to a remote command executer which would > be trusted because it was encrypted with a shared passphrase. This > shows that the last command say could be garbled, resulting in a null > operation and potential security problem. With known plaintext, the last 8 bytes can be set to anything the attacker desires - so it's not just a case of removing or randomly corrupting data. You can find the paper for the talk at: http://www.hotlava.com/doc/index.html Gary Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA19490 for ietf-open-pgp-bks; Tue, 6 Jan 1998 11:17:59 -0800 (PST) Received: from newmail.virgin.net ([194.168.54.44]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA19486 for ; Tue, 6 Jan 1998 11:17:52 -0800 (PST) Received: from server.eternity.org ([194.168.68.191]) by newmail.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 549-33929U100000L2S50) with ESMTP id AAB15501; Tue, 6 Jan 1998 19:21:40 +0000 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id SAA00377; Tue, 6 Jan 1998 18:31:21 GMT Date: Tue, 6 Jan 1998 18:31:21 GMT Message-Id: <199801061831.SAA00377@server.eternity.org> From: Adam Back To: ietf-open-pgp@imc.org Cc: gary@hotlava.com Cc: ianb@acm.org Subject: message integrity checksum? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Gary Howland discussed PGP vulnerabilities at HIP97 I think. One of the vulnerabilities was that encrypted (but not signed) messages could be altered undetectably. This can be demonstrated (with pgp2.6 command line): % echo hello world > junk % pgp -c +compress=off -zfred junk % sed 's/....$/adam/' < junk.pgp > junk2.pgp % pgp -zfred junk2.pgp % cat junk2 hello woP?t (pgp doesn't complain or even notice the above ... there is no checksum and so you can just garble the file, if you so wish, and pgp won't complain). Was this viewed as a problem? I think the example given is that someone might use this (symmetric encryption) to send commands to a remote command executer which would be trusted because it was encrypted with a shared passphrase. This shows that the last command say could be garbled, resulting in a null operation and potential security problem. The same problem applies to RSA (or Elgamal), encrypted messages, as the bulk of the data is encrypted with a block cipher essentially the same as the symmetric cipher only. Clearly one way to fix it is to use signatures. Was there any thought given to using a MAC, checksum, or message digest added to the message to prevent modification without knowing the key? Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA26765 for ietf-open-pgp-bks; Fri, 2 Jan 1998 10:47:45 -0800 (PST) Received: from CAraptorUU.geoworks.com (CAraptorUU.geoworks.com [208.232.87.36]) by mail.proper.com (8.8.7/8.7.3) with SMTP id KAA26761 for ; Fri, 2 Jan 1998 10:47:22 -0800 (PST) Received: from maelstrom.geoworks.com by CAraptorUU.geoworks.com via smtpd (for mail.proper.com [206.184.129.129]) with SMTP; 2 Jan 1998 18:50:10 UT Received: from fusion.geoworks.com (fusion.geoworks.com [198.211.200.200]) by maelstrom.geoworks.com (8.8.6/8.8.5) with ESMTP id KAA12543; Fri, 2 Jan 1998 10:50:10 -0800 (PST) Received: from quark.geoworks.com (quark.geoworks.com [198.211.201.100]) by fusion.geoworks.com (8.8.5/8.8.5) with ESMTP id KAA10017; Fri, 2 Jan 1998 10:50:08 -0800 (PST) Received: from ammonia.geoworks.com (ammonia.geoworks.com [198.211.201.16]) by quark.geoworks.com (8.8.5/8.8.5) with ESMTP id KAA00874; Fri, 2 Jan 1998 10:50:07 -0800 (PST) From: Curtis Yarvin Received: (from cyarvin@localhost) by ammonia.geoworks.com (8.8.5/8.8.5) id KAA16673; Fri, 2 Jan 1998 10:50:06 -0800 (PST) Message-Id: <199801021850.KAA16673@ammonia.geoworks.com> Subject: Re: Proposed Extensions to TLS for OpenPGP To: PADGETT@hobbes.orl.lmco.com (A. Padgett Peterson P.E. Information Security) Date: Fri, 2 Jan 1998 10:50:06 -0800 (PST) Cc: ietf-open-pgp@imc.org In-Reply-To: <980102120138.20209aa0@hobbes.orl.lmco.com> from "A. Padgett Peterson P.E. Information Security" at Jan 2, 98 12:01:38 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > For that matter PGP plugs in directly to EXCHANGE and EUDORA. To me > this just shows the impossibility of such a reg. unless plugins can > be owtlawed completely (of course that has never bothered any court > since King Canute). A slur! I must defend the name of good King Canute. Canute (Knut), a Danish king of England around 900 AD, was a fine ruler. In his reign, peace and high culture were restored; banditry was suppressed. He united Anglo-Saxon, British, and Danish peoples of England in a single prosperous kingdom. Canute (at least, according to the story) did have his throne carried down to the beach, did command the tide not to come in, and did sit there until it washed over his feet. However, his point was not to demonstrate his omnipotence, but his lack of such, to quit the flattery of his courtiers. Thus, Canute should not be remembered for arrogance and pomposity, but for wisdom, discretion, a good sense of humor, and strong managerial skills. Of course, the art of government has come a long way since the Dark Ages: it's unfair to compare him to any of our modern rulers. Curtis Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA24304 for ietf-open-pgp-bks; Fri, 2 Jan 1998 08:58:57 -0800 (PST) Received: from mailgw2.lmco.com (mailgw2.lmco.com [192.91.147.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA24298 for ; Fri, 2 Jan 1998 08:58:52 -0800 (PST) Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2.lmco.com (8.8.8/8.8.8) with ESMTP id MAA31067 for ; Fri, 2 Jan 1998 12:02:27 -0500 (EST) Received: from hobbes.orl.lmco.com ([141.240.192.100]) by lmco.com (PMDF V5.1-10 #20544) with SMTP id <0EM6002C51YYLY@lmco.com> for ietf-open-pgp@imc.org; Fri, 2 Jan 1998 12:01:46 -0500 (EST) Date: Fri, 02 Jan 1998 12:01:38 -0500 (EST) From: "A. Padgett Peterson P.E. Information Security" Subject: Re: Proposed Extensions to TLS for OpenPGP To: ekr@terisa.com Cc: ietf-open-pgp@imc.org Message-id: <980102120138.20209aa0@hobbes.orl.lmco.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >Incidentally, I think this is probably a dangerous course of >action. The EAR 7 day review >criteria explicitly state: > (iv) The software must not allow the alteration of the data >encryption mechanism and its associated key spaces by the user or >any other program For that matter PGP plugs in directly to EXCHANGE and EUDORA. To me this just shows the impossibility of such a reg. unless plugins can be owtlawed completely (of course that has never bothered any court since King Canute). Unless, of course, a good Kentuck lawyer could argue that "your honour, our program has not altered the data encryption mechanism or its associated key spaces, they are completely intact (just bypassed)." (and the MIB would come around with their little flasher thingie...). Warmly, Padgett Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA25017 for ietf-open-pgp-bks; Thu, 1 Jan 1998 21:09:18 -0800 (PST) Received: from lites.lvdi.net (lites.lvdi.net [208.129.21.10]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA25013 for ; Thu, 1 Jan 1998 21:09:14 -0800 (PST) Received: from [208.129.55.202] ([208.129.55.202]) by lites.lvdi.net (8.8.7/8.7.3) with ESMTP id UAA13457; Thu, 1 Jan 1998 20:56:58 -0800 (PST) X-Sender: schear@mail.lvdi.net (Unverified) Message-Id: In-Reply-To: <199801020333.TAA16477@itech.terisa.com> References: Your message of "Thu, 01 Jan 1998 17:40:52 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jan 1998 21:02:16 -0800 To: EKR From: Steve Schear Subject: Re: Proposed Extensions to TLS for OpenPGP Cc: ietf-tls@consensus.com, ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 7:34 PM -0800 1/1/98, EKR wrote: >You write: >> >Incidentally, I think this is probably a dangerous course of >> >action. The EAR 7 day review >> >criteria explicitly state: >> > >> > (iv) The software must not allow the alteration of the data=20 >> >encryption mechanism and its associated key spaces by the user or=20 >> >any other program >> > >> >It seem that Fortify is a constructive proof that the program >> >in question violates this criterion. That doesn't mean it's >> >ineligible for CJ completely but I wouldn't want to try to get >> >approval for it either. >>=20 >> I'm sure the EAR enforcement folks are well aware of how well or poorly= various software they approve for export adhere to regulation. I'll leave= it to the individual corporations and EAR to soft this out. >>=20 >> The point I was trying to make is that from a practical standpoint >> companies like Netscape need change nothing. Just keep their code >> structured the same way and let unrelated 3rd parties "do the dirty >> work."=20 >I think we're in violent agreement here, then. Some companies have a strong idiological calling and need to follow that= star (i.e., PGP). Others are spineless jellyfish who go along to get= along, hoping that this path will keep them in the good graces of the Dept.= of Commerce. Many fall somewhere in between. =20 I don't see Netscape playing the martyr or using PGP/C2's legal guerilla= tactics to enbable strong crypto systems and applications, it's just not= their style. They do seem to be, however, keenly aware of the PR= associated with championing reliable transaction privacy and the adverse PR= from being hacked (especially from weak crypto). Keeping their products= hackable, perhaps even anonymously supporting those doing the hacking,= while staying within the letter of the law and publicly and privately= pressuring for true crypto reform might be their best course. =46or many, including myself, guerilla tactics are more attractive due to= economic factors. Also, I have less to lose. --Steve PGP mail preferred, see http://www.pgp.com and http://web.mit.edu/network/pgp.html RSA fingerprint: FE90 1A95 9DEA 8D61 812E CCA9 A44A FBA9 RSA key: http://keys.pgp.com:11371/pks/lookup?op=3Dindex&search=3D0x55C78B0D --------------------------------------------------------------------- Steve Schear | tel: (702) 658-2654 CEO | fax: (702) 658-2673 =46irst ECache Corporation | 7075 West Gowan Road | Suite 2148 | Las Vegas, NV 89129 | Internet: schear@lvdi.net --------------------------------------------------------------------- I know not what course others may take; but as for me,=20 give me ECache or give me debt! "It's your Cache=81" Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA24354 for ietf-open-pgp-bks; Thu, 1 Jan 1998 19:29:43 -0800 (PST) Received: from terisa-bh.terisa.com (terisa-bh.terisa.COM [205.226.38.66]) by mail.proper.com (8.8.7/8.7.3) with SMTP id TAA24350 for ; Thu, 1 Jan 1998 19:29:39 -0800 (PST) Received: (from uucp@localhost) by terisa-bh.terisa.com (8.6.12/8.6.11) id TAA05489; Thu, 1 Jan 1998 19:33:09 -0800 Received: from itech.terisa.com by terisa-bh.terisa.com via smap (3.2) id xma005487; Thu, 1 Jan 98 19:33:08 -0800 Received: from kmac.terisa.COM (kmac.terisa.COM [205.226.39.35]) by itech.terisa.com (8.8.5/8.6.4) with SMTP id TAA16477; Thu, 1 Jan 1998 19:33:18 -0800 (PST) Message-Id: <199801020333.TAA16477@itech.terisa.com> To: Steve Schear cc: ietf-tls@consensus.com, ietf-open-pgp@imc.org Subject: Re: Proposed Extensions to TLS for OpenPGP In-reply-to: Your message of "Thu, 01 Jan 1998 17:40:52 PST." Date: Thu, 01 Jan 1998 19:34:59 -0800 From: EKR Sender: owner-ietf-open-pgp@imc.org Precedence: bulk You write: > >Incidentally, I think this is probably a dangerous course of > >action. The EAR 7 day review > >criteria explicitly state: > > > > (iv) The software must not allow the alteration of the data > >encryption mechanism and its associated key spaces by the user or > >any other program > > > >It seem that Fortify is a constructive proof that the program > >in question violates this criterion. That doesn't mean it's > >ineligible for CJ completely but I wouldn't want to try to get > >approval for it either. > > I'm sure the EAR enforcement folks are well aware of how well or poorly various software they approve for export adhere to regulation. I'll leave it to the individual corporations and EAR to soft this out. > > The point I was trying to make is that from a practical standpoint > companies like Netscape need change nothing. Just keep their code > structured the same way and let unrelated 3rd parties "do the dirty > work." I think we're in violent agreement here, then. -Ekr [Eric Rescorla Terisa Systems, Inc.] "Put it in the top slot." Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA24065 for ietf-open-pgp-bks; Thu, 1 Jan 1998 18:40:27 -0800 (PST) Received: from lites.lvdi.net (lites.lvdi.net [208.129.21.10]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA24061 for ; Thu, 1 Jan 1998 18:40:23 -0800 (PST) Received: from [208.129.55.202] ([208.129.55.202]) by lites.lvdi.net (8.8.7/8.7.3) with ESMTP id SAA09409; Thu, 1 Jan 1998 18:35:35 -0800 (PST) X-Sender: schear@mail.lvdi.net Message-Id: In-Reply-To: <199801012028.MAA15455@itech.terisa.com> References: Your message of "Thu, 01 Jan 1998 10:58:03 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jan 1998 17:40:52 -0800 To: EKR From: Steve Schear Subject: Re: Proposed Extensions to TLS for OpenPGP Cc: ietf-tls@consensus.com, ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >> At 7:00 PM -0800 12/31/97, EKR wrote: >Sorry I wasn't clear. The point I was trying to make was >that Netscape would still have to ship their export products, no? >Otherwise Fortify doesn't work, right? That said, there will be >a lot of people who don't bother to upgrade (just like there >are a lot of Americans who don't bother to get the domestic >Netscape.) Consequently, we've still got a lot of export >SSL implementations floating around. Does that seem like a=20 >reasonable assessment of the situation to you? Like markets, in which there will always be some who pay more or less for= the same item/service due primarily to their knowledge, there will be those= who's communications will be more easily compromised and other's who will= not. This is a job for the media and informed Netizens: to educate their= brethern about how secure the software they use is against various= individuals or organizations which would seek to read their email, and what= they can do about it.=20 > >Incidentally, I think this is probably a dangerous course of >action. The EAR 7 day review >criteria explicitly state: > > (iv) The software must not allow the alteration of the data=20 >encryption mechanism and its associated key spaces by the user or=20 >any other program > >It seem that Fortify is a constructive proof that the program >in question violates this criterion. That doesn't mean it's >ineligible for CJ completely but I wouldn't want to try to get >approval for it either. I'm sure the EAR enforcement folks are well aware of how well or poorly= various software they approve for export adhere to regulation. I'll leave= it to the individual corporations and EAR to soft this out. The point I was trying to make is that from a practical standpoint companies= like Netscape need change nothing. Just keep their code structured the= same way and let unrelated 3rd parties "do the dirty work." --Steve Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA22342 for ietf-open-pgp-bks; Thu, 1 Jan 1998 13:39:11 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA22338 for ; Thu, 1 Jan 1998 13:39:07 -0800 (PST) Received: from users.invweb.net (ppp21.dotstar.net [208.143.93.40]) by users.invweb.net (8.8.7/8.8.7) with SMTP id QAA25800; Thu, 1 Jan 1998 16:46:03 -0500 Message-Id: <199801012146.QAA25800@users.invweb.net> From: "William H. Geiger III" Date: Thu, 01 Jan 98 15:36:23 -0600 To: EKR In-Reply-To: <199801012028.MAA15455@itech.terisa.com> Cc: Steve Schear , ietf-tls@consensus.com, ietf-open-pgp@imc.org, ekr@terisa-bh.terisa.com Subject: Re: Proposed Extensions to TLS for OpenPGP X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <199801012028.MAA15455@itech.terisa.com>, on 01/01/98 at 03:29 PM, EKR said: >It seem that Fortify is a constructive proof that the program in question >violates this criterion. That doesn't mean it's >ineligible for CJ completely but I wouldn't want to try to get approval >for it either. Personaly I think it would be a far better thing to allow *no* crypto products be exported rather than the current government mandated snake-oil. FWIW: Most people I talk to that need the strong crypto version overseas get it from replay.com :) - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKwNBI9Co1n+aLhhAQEungP8D8coWXBmAC25U8B4QeUxRc3jLWMGNxEP YOCRkkmSJPumW18j5u5zMyrtYyjzm0OoudPzUFl8NpLaASHeRQPPUT/Ld9kUxe6T VzANhfK2fqsGhxMhUkpNdSLxjxPB7glg+8MUJkA6tppo9GQ/gQclyFIqbVX6aqOX I6uzBBw67Io= =oEv8 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA22172 for ietf-open-pgp-bks; Thu, 1 Jan 1998 13:08:48 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA22168 for ; Thu, 1 Jan 1998 13:08:45 -0800 (PST) Received: from users.invweb.net (ppp21.dotstar.net [208.143.93.40]) by users.invweb.net (8.8.7/8.8.7) with SMTP id QAA25547; Thu, 1 Jan 1998 16:18:53 -0500 Message-Id: <199801012118.QAA25547@users.invweb.net> From: "William H. Geiger III" Date: Thu, 01 Jan 98 15:02:32 -0600 To: Hal Finney In-Reply-To: <199801011939.LAA08279@s20.term1.sb.rain.org> Cc: ietf-open-pgp@imc.org, pgp-dev@pgpi.com Subject: Re: Key Extraction odd behavior ??? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <199801011939.LAA08279@s20.term1.sb.rain.org>, on 01/01/98 at 11:39 AM, Hal Finney said: >What is packet type 14? You seem hung up on the idea that it is a >signature packet. It's not! Look at section 4.3: Yes, after a good nights sleep and some help from Patrick I was able to figure it out. Part of my mental block was I *knew* that there should have been a sig packet following the userID packet. As far as the striping of the signatures: I did a pgpk -x [keyID] -o [outfile] The signature packets should have been retained in the extracted key in the outfile but for some reason they were striped. I have not been able to isolate the exact triger for this happening as I have latter done the same operation and had the sig packets retained. IMHO I can not see any reason for a sig packet to be removed from a key unless they are flaged as non-exportable or the user explicitly removes them. This seems to be some type of bug in the 5.0i code as I have had other problems with the pgpk code from this build (b8a). BTW any ideal what setting a key as "axiomatic" does?? - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKwGpo9Co1n+aLhhAQHqxAP+IdMAt7KvDy1zLl+fi5zfH8xO9h0/Kdy1 YvCzWCCDHRjg/xfgjYUaduvH+uWecvm5xY4RJ8EkzLGZgiCSginTPkw9iMYup7DL f4YvNijSKOue3BqlCHs7yzdtqPw+XHRmPkWhQ6YrKYudoeVrt8YJ7YrF3HxxLwhZ y6/q4nEEoMA= =HqQV -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA22102 for ietf-open-pgp-bks; Thu, 1 Jan 1998 12:59:36 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA22097 for ; Thu, 1 Jan 1998 12:59:31 -0800 (PST) Received: from users.invweb.net (ppp21.dotstar.net [208.143.93.40]) by users.invweb.net (8.8.7/8.8.7) with SMTP id QAA25424; Thu, 1 Jan 1998 16:06:10 -0500 Message-Id: <199801012106.QAA25424@users.invweb.net> From: "William H. Geiger III" Date: Thu, 01 Jan 98 14:52:36 -0600 To: Steve Schear In-Reply-To: Cc: EKR , EKR , ietf-tls@consensus.com, ietf-open-pgp@imc.org, ekr@terisa-bh.terisa.com Subject: Re: Proposed Extensions to TLS for OpenPGP X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In , on 01/01/98 at 10:58 AM, Steve Schear said: >Sure it does. (Hello, are you listening?) Fortify modifies the currently >shipping, currently export approved Navigator/Communicator, allowing >users anywhere to use its 128-bit SSL whenever they connect with a >128-bit capable SSL server (say a cypherpunk server at XS4all in the >Netherlands). Normally, 128-bit SSL is only enabled when these browsers >connect with an SSL server which has a "supercert" issued with U.S. gov't >approval (mostly to U.S. banks). >So strong crypto is now available, via an easily applied patch, to the >most widely used export approved product. Another approach that I have been playing with is the use of local crypto proxies. One would have a HTTP/SSL proxie that uses strong crypto and comes with source code. One mearly connects their web borwser to their proxie and the proxie handles all the crypto. For non crypto sites it would just pass the pages and requests through unmolested. I have also looked into adding SSH capabilities to this so even non-SSL sites one can still tunnel via SSH for an encrypted link. A similar approach can be used for addressing the weak S/MIME crypto produced by NS, MS, et al. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKwDrI9Co1n+aLhhAQED5wP/YrMxrU9KNXKI+3Lk/3bat4aKzT738uXl hjrqKq6s5CL1+CGGaYUszivbTPDQg/aDR3AEgceepx3FgIFSNR6Mh0oLsoKFVC+9 Ieh4YP+9Gh2D/PDjd3kYxeCKK2fxZWB/C6cHDsxRXMtO1k5raYE1SoptPozXICs5 Lh62RvT27fw= =0jh6 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA21899 for ietf-open-pgp-bks; Thu, 1 Jan 1998 12:24:45 -0800 (PST) Received: from terisa-bh.terisa.com (terisa-bh.terisa.COM [205.226.38.66]) by mail.proper.com (8.8.7/8.7.3) with SMTP id MAA21895 for ; Thu, 1 Jan 1998 12:24:41 -0800 (PST) Received: (from uucp@localhost) by terisa-bh.terisa.com (8.6.12/8.6.11) id MAA01491; Thu, 1 Jan 1998 12:28:10 -0800 Received: from itech.terisa.com by terisa-bh.terisa.com via smap (3.2) id xma001489; Thu, 1 Jan 98 12:28:07 -0800 Received: from kmac.terisa.COM (kmac.terisa.COM [205.226.39.35]) by itech.terisa.com (8.8.5/8.6.4) with SMTP id MAA15455; Thu, 1 Jan 1998 12:28:16 -0800 (PST) Message-Id: <199801012028.MAA15455@itech.terisa.com> To: Steve Schear cc: ietf-tls@consensus.com, ietf-open-pgp@imc.org, ekr@terisa-bh.terisa.com Subject: Re: Proposed Extensions to TLS for OpenPGP In-reply-to: Your message of "Thu, 01 Jan 1998 10:58:03 PST." Date: Thu, 01 Jan 1998 12:29:57 -0800 From: EKR Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > At 7:00 PM -0800 12/31/97, EKR wrote: > >In message , Steve Schear writes: > >>How about funding programs such as Fortify, which patch browsers to enable 128 > >>-bit SSL with all willing servers (whether or not they have supercerts)? > >That seems like a fine plan, but it doesn't really speak to what > >Netscape ships as a Netscape product, does it? > > > >-Ekr > Sure it does. (Hello, are you listening?) Fortify modifies the > currently shipping, currently export approved > Navigator/Communicator, allowing users anywhere to use its 128-bit > SSL whenever they connect with a 128-bit capable SSL server (say a > cypherpunk server at XS4all in the Netherlands). Normally, 128-bit > SSL is only enabled when these browsers connect with an SSL server > which has a "supercert" issued with U.S. gov't approval (mostly to > U.S. banks). > So strong crypto is now available, via an easily applied patch, to > the most widely used export approved product. Sorry I wasn't clear. The point I was trying to make was that Netscape would still have to ship their export products, no? Otherwise Fortify doesn't work, right? That said, there will be a lot of people who don't bother to upgrade (just like there are a lot of Americans who don't bother to get the domestic Netscape.) Consequently, we've still got a lot of export SSL implementations floating around. Does that seem like a reasonable assessment of the situation to you? Incidentally, I think this is probably a dangerous course of action. The EAR 7 day review criteria explicitly state: (iv) The software must not allow the alteration of the data encryption mechanism and its associated key spaces by the user or any other program It seem that Fortify is a constructive proof that the program in question violates this criterion. That doesn't mean it's ineligible for CJ completely but I wouldn't want to try to get approval for it either. -Ekr [Eric Rescorla Terisa Systems, Inc.] "Put it in the top slot." Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA21771 for ietf-open-pgp-bks; Thu, 1 Jan 1998 12:00:39 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA21767 for ; Thu, 1 Jan 1998 12:00:35 -0800 (PST) Received: from s20.term1.sb.rain.org (s06.term1.sb.rain.org [198.68.144.136]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id LAA28249; Thu, 1 Jan 1998 11:55:22 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id LAA08279; Thu, 1 Jan 1998 11:39:01 -0800 Date: Thu, 1 Jan 1998 11:39:01 -0800 From: Hal Finney Message-Id: <199801011939.LAA08279@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org, pgp-dev@pgpi.com Subject: Re: Key Extraction odd behavior ??? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk William, simply decode the packets as specified by the draft: 0xb9 = 10111001 = 10 1110 01, packet type 14. What is packet type 14? You seem hung up on the idea that it is a signature packet. It's not! Look at section 4.3: : 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 -- Marker Packet : 11 -- Literal Data Packet : 12 -- Trust Packet : 13 -- Name Packet : 14 -- Subkey Packet : 15 -- Reserved : 16 -- Comment Packet Packet type 14 is a subkey packet. It's not a signature packet. You are completely mistaken in trying to interpret it as one. The format of packet type 14 is in section 5.5.1.2 of the draft, where it is explained that the same format is used as for a public key packet. These are defined in 5.5.2. There you will see: : A version 4 packet contains: : - A one-octet version number (4). : - A four-octet number denoting the time that the key was created. : - A one-octet number denoting the public key algorithm of this key : - A series of multi-precision integers comprising the key : material. This algorithm-specific portion is: : : Algorithm Specific Fields for RSA public keys: : - multiprecision integer (MPI) of RSA public modulus n; : - MPI of RSA public encryption exponent e. : : Algorithm Specific Fields for DSA public keys: : - MPI of DSA prime p; : - MPI of DSA group order q (q is a prime divisor of p-1); : - MPI of DSA group generator g; : - MPI of DSA public key value y (= g**x where x is secret). : : Algorithm Specific Fields for Elgamal public keys: : - MPI of Elgamal prime p; : - MPI of Elgamal group generator g; : - MPI of Elgamal public key value y (= g**x where x : is secret). This will explain the format of your packet. As to your problem with the signatures sometimes being exported and sometimes not: this usually means you are changing to a different public keyring without also changing your secret keyring. Signature packets are stored on the public keyring only, in 5.0 and earlier versions. Key and userid packets are stored on both public and private keyrings. If you change to a different public keyring file, you'll still see your old key and userid, because they are stored on the secret keyring, which you didn't change. But if you look for signatures, you will see that they are now absent. That is because they were only stored in the original public keyring file. If you export now you will get a key without signatures. This behavior goes back to PGP 2.X, and is due to the desire to segregate the sensitive key material from the public material. However there is some worry that it causes confusion like it has for you, and therefore we might want to consider abandoning the dual-key-ring model and go to a single file to store all the key/certificate information. Hal Finney PGP, Inc. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA21563 for ietf-open-pgp-bks; Thu, 1 Jan 1998 11:08:53 -0800 (PST) Received: from mailgw2.lmco.com (mailgw2.lmco.com [192.91.147.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA21559 for ; Thu, 1 Jan 1998 11:08:49 -0800 (PST) Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2.lmco.com (8.8.8/8.8.8) with ESMTP id OAA26176 for ; Thu, 1 Jan 1998 14:12:16 -0500 (EST) Received: from hobbes.orl.lmco.com ([141.240.192.100]) by lmco.com (PMDF V5.1-10 #20544) with SMTP id <0EM4009Z3DBBKD@lmco.com> for ietf-open-pgp@imc.org; Thu, 1 Jan 1998 14:11:35 -0500 (EST) Date: Thu, 01 Jan 1998 14:11:25 -0500 (EST) From: "A. Padgett Peterson P.E. Information Security" Subject: Re: Proposed Extensions to TLS for OpenPGP To: schear@lvdi.net Cc: ietf-open-pgp@imc.org Message-id: <980101141125.20209e48@hobbes.orl.lmco.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk DRAT. I remember seeing somewhere that changing the crypto in either EXCHANGE or NETSCAPE (might be both) was a matter of exchanging a .DLL but cannot recall the citation - anyone here know ? Hippo Neuw Jahr, Padgett Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA21541 for ietf-open-pgp-bks; Thu, 1 Jan 1998 11:07:31 -0800 (PST) Received: from lites.lvdi.net (lites.lvdi.net [208.129.21.10]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA21537 for ; Thu, 1 Jan 1998 11:07:27 -0800 (PST) Received: from [208.129.55.202] ([208.129.55.202]) by lites.lvdi.net (8.8.7/8.7.3) with ESMTP id LAA26479; Thu, 1 Jan 1998 11:02:40 -0800 (PST) X-Sender: schear@mail.lvdi.net Message-Id: In-Reply-To: <199801010258.SAA07113@itech.terisa.com> References: Your message of "Wed, 31 Dec 1997 16:28:19 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jan 1998 10:58:03 -0800 To: EKR From: Steve Schear Subject: Re: Proposed Extensions to TLS for OpenPGP Cc: EKR , ietf-tls@consensus.com, ietf-open-pgp@imc.org, ekr@terisa-bh.terisa.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 7:00 PM -0800 12/31/97, EKR wrote: >In message , Steve Schear writes: >>At 2:25 PM -0800 12/31/97, EKR wrote: >>>Will Price writes: >>>> At 11:15 PM -0800 12/30/97, Eric Rescorla wrote: >> >>[big snip] >>>Try to solve the following two examples: >>>Netscape and Microsoft. Netscape has downloads off their web site. >>>They want them to be easy. That means that the user can just >>>point and click. That means the crypto must be exportable or none >>>at all. Which do you suggest? >>>Next consider Microsoft. They embed their browser in the OS (at >>>least for now.). They want to ship that to foreigners. Again, >>>the crypto has to be exportable or nonexistent. Which do you >>>suggest? >>> >>>So, what do you suggest these companies do? >> >>How about funding programs such as Fortify, which patch browsers to enable= 128 >>-bit SSL with all willing servers (whether or not they have supercerts)? >That seems like a fine plan, but it doesn't really speak to what >Netscape ships as a Netscape product, does it? > >-Ekr Sure it does. (Hello, are you listening?) Fortify modifies the currently= shipping, currently export approved Navigator/Communicator, allowing users= anywhere to use its 128-bit SSL whenever they connect with a 128-bit= capable SSL server (say a cypherpunk server at XS4all in the Netherlands). = Normally, 128-bit SSL is only enabled when these browsers connect with an= SSL server which has a "supercert" issued with U.S. gov't approval (mostly= to U.S. banks). So strong crypto is now available, via an easily applied patch, to the most= widely used export approved product. --Steve Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA21529 for ietf-open-pgp-bks; Thu, 1 Jan 1998 11:05:49 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA21525 for ; Thu, 1 Jan 1998 11:05:45 -0800 (PST) Received: from users.invweb.net (ppp23.dotstar.net [208.143.93.42]) by users.invweb.net (8.8.7/8.8.7) with SMTP id OAA24465; Thu, 1 Jan 1998 14:15:42 -0500 Message-Id: <199801011915.OAA24465@users.invweb.net> From: "William H. Geiger III" Date: Thu, 01 Jan 98 12:56:05 -0600 To: Patrick Feisthammel In-Reply-To: Cc: IETF OpenPGP Mailinglist , pgp-dev@pgpi.com Subject: Re: Key Extraction odd behavior ??? [Solved] X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In , on 01/01/98 at 07:40 PM, Patrick Feisthammel said: >"A Public Subkey packet (tag 14) has exactly the same format as a Public >Key packet, but denotes a subkey" Sorry People, I guess I shouldn't read rfc's at 2am. :) I was mistaking the "Public Subkey Packet" for a Signature SubPacket. Forget all my previous ranting. Still don't know why PGP 5.0 striped off the sigs when exporting the key but that is not an issue for OpenPGP. Thanks Patrick for putting up with my ranting. :) - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKvpyo9Co1n+aLhhAQFWzAQAjnt0m3hquNNyZVOGoz0hZPeIcuJEcyOL oLwc1cqcwN8LVSr1R9PpXeKhu4h1EoSreI1us6no0twmqPwFIGYvw3WJ5KfIup87 zY2+STOaU974bijOgziMYDCISKu0f8YZUz9zLnkyZONzXkrue1dDdMpk1DQ+liDO EZ9nOrUYEOw= =6E3s -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA21392 for ietf-open-pgp-bks; Thu, 1 Jan 1998 10:38:10 -0800 (PST) Received: from dns.cyberlink.ch (root@dns.cyberlink.ch [193.246.253.10]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA21387 for ; Thu, 1 Jan 1998 10:38:06 -0800 (PST) Received: from dns.rubin.ch (root@gwrubin.cyberlink.ch [193.246.253.129]) by dns.cyberlink.ch (8.8.4/8.8.4) with ESMTP id TAA27750; Thu, 1 Jan 1998 19:41:24 +0100 Received: from dns.rubin.ch (pafei@dns.rubin.ch [193.246.253.130]) by dns.rubin.ch (8.8.5/8.8.5) with SMTP id TAA13240; Thu, 1 Jan 1998 19:40:58 +0100 Date: Thu, 1 Jan 1998 19:40:54 +0100 (CET) From: Patrick Feisthammel Reply-To: Patrick Feisthammel To: "William H. Geiger III" cc: IETF OpenPGP Mailinglist , pgp-dev@pgpi.com Subject: Re: Key Extraction odd behavior ??? In-Reply-To: <199801011625.LAA23138@users.invweb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hi! > Version Number is defined for Signature Packets (Type 2) and not for > Signatuer Subpacket (Type 14). It is not a signature packet (typ 2). In teh OpenPGP draft you find: 5.5.1.2 Public Subkey Packte (Tag 14): "A Public Subkey packet (tag 14) has exactly the same format as a Public Key packet, but denotes a subkey" The Public Key Packet (Tag 6): "starts a series of packets that forms an OP key". (I think in the specs in chapter 5.5.1.1 should be a forward reference to the chapter 5.5.2) Some lines later in 5.5.2 "Public Key Packet Formats": "There are two versions of key-material packets. Version 3..." > The next octet is 0x34 what is that?? It doesn't match as a signature type > nor does it match for a signatuer subpacket type. The version 4 packet contains: " - A one-octed version number (4). - A four-octet number denoting the time that the key was created. ... " >>[B9] [04 0D] 04 34 A3 DF 8E ... so 34 A3 DF 8E is the time the key was created. (I think late in 1997, not exactly calculated) > Also in the spec it does not define exactly which bits from a subpacket > type octet are to be used for determining the value? Bit 7 is defined as a > critical flag so do we use the remaining 6-0 bits or a subset of that? I could not find an exact definition. The last 5 Bits (Bits 4-0) must be for the type, Bit 7 is the critical Bit. So there are still Bit 5 and 6 left. Maybe they will become some special meaning in the future, maybe they are just used for furthter packages... Cheers, Patrick - --- PGP-KeyID: DD934139 (pafei@rubin.ch) encrypt mail with PGP if possible more about PGP on http://www.rubin.ch/pgp/ (english and german) -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQESAwUBNKvjOZVgYabdk0E5AQEdxQfkCM7C34jVQ5BDbtDV0fMgq3aI5V+GuhhZ ZCHjOUM5f0Zwi3RYG7nrP3IyUOFMYy+4yEQ1XVOn5thBk/ZRC0w9KFC1xRz+ziDd t/jyZCMgj89I124yCI1XuX77QMI6vJOZeK7R3vZX9hnEusskPONpbe4FaC30VDqw JcMXa/RjOZcHjKb8bt3pHPRlrfd7FC9GGSgGO6os1q0a1Nj+qXn6QeWonz/rPkzg eZ4b5QBrHQVmm/mpHAqjUkgFqbll+eQ/L3TBJuyMOpvwFGytEvpNYsv7T3PCoTZx H+XyY8kfvF6G4UD5AbY0tKsOX+oOXAuifgHJ1IjORmjnQYfHJA== =uRZO -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA20558 for ietf-open-pgp-bks; Thu, 1 Jan 1998 08:16:05 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA20554 for ; Thu, 1 Jan 1998 08:16:01 -0800 (PST) Received: from users.invweb.net (cppp06.dotstar.net [208.143.93.106]) by users.invweb.net (8.8.7/8.8.7) with SMTP id LAA23138; Thu, 1 Jan 1998 11:25:48 -0500 Message-Id: <199801011625.LAA23138@users.invweb.net> From: "William H. Geiger III" Date: Thu, 01 Jan 98 10:08:53 -0600 To: pafei@rubin.ch In-Reply-To: Cc: ietf-open-pgp@imc.org, pgp-dev@pgpi.com Subject: Re: Key Extraction odd behavior ??? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In , on 01/01/98 at 10:05 AM, Patrick Feisthammel said: >-----BEGIN PGP SIGNED MESSAGE----- >Hi! >> If [B9] is the packet type and [04 0D] the packet length what is the next >> [04]? >B9= 1011 1001 >10= old packet type >1110= packet typ 14 (decimal) >01-> 2 octed length >I think it is a packet 14 (subkey packet), 040d is the length. the next >04 is the version number (version 4 packet) >as given in the OpenPGP draft in Chapter 5.5.2. Public Key Packet >Formats. Hi Patric, Unfortunatly this doen not seem to work. Version Number is defined for Signature Packets (Type 2) and not for Signatuer Subpacket (Type 14). The next octet is 0x34 what is that?? It doesn't match as a signature type nor does it match for a signatuer subpacket type. Also in the spec it does not define exactly which bits from a subpacket type octet are to be used for determining the value? Bit 7 is defined as a critical flag so do we use the remaining 6-0 bits or a subset of that? - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKvB+49Co1n+aLhhAQHOHgQAm36yAw2I+pOVy1ejPljiYW7Irug2CTND HDau+AsoVrF5xeeRGTud7Ki62XyxMY8dVgbnyHXbSbV4VOb3rHe1uCTjG6bdxExB KrkLGKt0OMj8BuBfNxxnF94f8uEwzYqyJvfI+e58nWY6/9IWtt/uO3r5aYduBnB+ XiA9uHvlNKw= =z1RE -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA20159 for ietf-open-pgp-bks; Thu, 1 Jan 1998 07:03:09 -0800 (PST) Received: from ln.active.ch (root@ln.active.ch [193.246.240.19]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA20155 for ; Thu, 1 Jan 1998 07:03:04 -0800 (PST) Received: from dns.rubin.ch (listen@dial-pri20-na.active.ch [193.135.163.130]) by ln.active.ch (8.8.7/8.8.6) with ESMTP id QAA27025; Thu, 1 Jan 1998 16:07:18 +0100 Received: from localhost (listen@localhost) by dns.rubin.ch (8.8.5/8.8.5) with SMTP id QAA10781; Thu, 1 Jan 1998 16:05:51 +0100 Date: Thu, 1 Jan 1998 16:05:46 +0100 (CET) From: Patrick Feisthammel Reply-To: pafei@rubin.ch To: "William H. Geiger III" cc: ietf-open-pgp@imc.org, pgp-dev@pgpi.com Subject: Re: Key Extraction odd behavior ??? In-Reply-To: <199801010911.EAA19898@users.invweb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hi! > If [B9] is the packet type and [04 0D] the packet length what is the next > [04]? B9= 1011 1001 10= old packet type 1110= packet typ 14 (decimal) 01-> 2 octed length I think it is a packet 14 (subkey packet), 040d is the length. the next 04 is the version number (version 4 packet) as given in the OpenPGP draft in Chapter 5.5.2. Public Key Packet Formats. Hope it helps :-) Cheers, Patrick -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQESAwUBNKuwzpVgYabdk0E5AQFe9AfhAQz8ir8znARINpowGQ3msvIVWe3LMizH 4+shVscLFsoU8zl5/PIfDPUFTs0BjjxXJ+ldSWhmYawjgNeXUTRdC+o8r7yksHN4 ozLz+DIxxvMjsL0xDKVK+kQU0PFPO7j2EXxqXOcM6X3ZTAeeXa4bsyKFT9UlGnrp 0bpumFsBzwf0wdHodeQXAEO75vt/X0E6fOrbrx0vwUIMKVRGNHXxT5DbRtzMEVhO liZKeG1SdneIjZtJudkfAysq3TmjlaR0ZALDtvLpTyw4goJ3MoG3C/WE5+q7n5kr hoc6JqbXia0tHg+CgOHKere3JvOc5yPHsErSrIQz2z+Rd4nXAw== =VZ0g -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA16846 for ietf-open-pgp-bks; Thu, 1 Jan 1998 01:01:51 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA16842 for ; Thu, 1 Jan 1998 01:01:46 -0800 (PST) Received: from users.invweb.net (cppp20.dotstar.net [208.143.93.120]) by users.invweb.net (8.8.7/8.8.7) with SMTP id EAA19898; Thu, 1 Jan 1998 04:11:15 -0500 Message-Id: <199801010911.EAA19898@users.invweb.net> From: "William H. Geiger III" Date: Thu, 01 Jan 98 02:47:06 -0600 To: ietf-open-pgp@imc.org, pgp-dev@pgpi.com In-Reply-To: <199801010617.BAA18412@users.invweb.net> Subject: Re: Key Extraction odd behavior ??? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.43 b43 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <199801010617.BAA18412@users.invweb.net>, on 01/01/98 at 01:10 AM, "William H. Geiger III" said: >Hi, >Well somthing screwy is going on. >I have now after doing several extracts of the same key from pubring.pkr >have two different keys?!? >I have the one of filesize 1504 that was attached to the previous message >and one of 1800 that seems to have the sig block properly >formatted. Ok I figured out *what* it is doning but not why. The original key had 2 sigs on it; one a self-sig and the other a RSA sig from my RSA key. The key contained packets: Public Key Packet UserID Packet Signature Packet (self-sig) Signature SubPacket Signatuer Packet (RSA sig) For some reason in the extracted key in the first message both signature packets had been striped from the key when extracted while in the extracted key in the second message they were retained. I still do not know what triggered this behavior. Well with that figured out I am back to my original problem of decyphering the Signature Subpacket. What I need to know is the following: [B9] [04 0D] 04 34 A3 DF 8E ... If [B9] is the packet type and [04 0D] the packet length what is the next [04]? If [04] is a subpacket length then what is the [34]? 0x34 = 00110100 = 52 which is an undefined subpacket type If [04] is a subpacket type (exportable) where is the corresponding octet flag? I have been up all night reading through the draft on this and still have not made any headway. :(( - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNKtcK49Co1n+aLhhAQGxbwP8DpmiEgfXC1kl5WLEjL8mGQI4fv3zKiFf vQ9ltFzG7UvL/gHC4Dhy1Nnxf0qcnQAd4Ih0ngZdMXmtz3eXIiWbdKouqBXJZZMc KoRqcVZcG4keaqa2Qr155BZkxZVsDW90ykkw/QClN9JyQHoNz3UDjTQnr4Va5F64 xJXErKxEsXQ= =HHhY -----END PGP SIGNATURE-----