Re: typo in rfc2440: secret key packet format
hal@finney.org Fri, 30 July 1999 17:17 UTC
Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06912 for <openpgp-archive@odin.ietf.org>; Fri, 30 Jul 1999 13:17:42 -0400 (EDT)
Received: by mail.proper.com (8.9.3/8.9.3) id JAA11825 for ietf-open-pgp-bks; Fri, 30 Jul 1999 09:45:43 -0700 (PDT)
Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA11821 for <ietf-open-pgp@imc.org>; Fri, 30 Jul 1999 09:45:38 -0700 (PDT)
From: hal@finney.org
Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id JAA14668; Fri, 30 Jul 1999 09:49:52 -0700
Date: Fri, 30 Jul 1999 09:49:52 -0700
Message-Id: <199907301649.JAA14668@finney.org>
To: hal@finney.org, sven@krypt1.cs.uni-sb.de
Subject: Re: typo in rfc2440: secret key packet format
Cc: ietf-open-pgp@imc.org
Sender: owner-ietf-open-pgp@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe>
Sven Wohlgemuth, <sven@krypt1.cs.uni-sb.de>, writes: > Has a string-to-key specifier to follow the specification of the symmetric > algorithm? It does, if there was a 255 and then the symmetric algorithm. It must not, if you just put in the symmetric algorithm and didn't put a 255 first. > Since I can use the MD5 hash value of the passphrase as a symmetric key. > Why should I write > 255, 1 > if I just want to use a symmetric algorithm without a s2k-specifier? You don't have to. > > >> - One octet indicating string-to-key usage conventions. 0 > >> indicates that the secret key data is not encrypted. 255 > >> indicates that a string-to-key specifier is being given. Any > === > >> other value is a symmetric-key encryption algorithm specifier. > ============================================================= > Isn't it possible to write > 1, enc_MPI, ... > 1 for the sym. algorithm follwed by the encrypted MPIs, instead? Almost. There needs to be an IV before the encrypted MPIs start. The idea is that there are three formats. Unencrypted looks like: 0, MPI, ... The simpler encrypted case is similar to your last suggestion: <symmetric-alg>, <IV>, enc_MPI, ... This uses the default "simple" string-to-key conventions. The more complex one is: 255, <symmetric-alg>, <string-to-key>, <IV>, enc_MPI, ... This allows you to specify a different string to key specifier. That is the reason for the more complex format. The iterated/salted string-to-key is superior as it makes it harder to guess passphrases for someone who gets hold of the private key. Hal Finney Received: by mail.proper.com (8.9.3/8.9.3) id JAA11825 for ietf-open-pgp-bks; Fri, 30 Jul 1999 09:45:43 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA11821 for <ietf-open-pgp@imc.org>; Fri, 30 Jul 1999 09:45:38 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id JAA14668; Fri, 30 Jul 1999 09:49:52 -0700 Date: Fri, 30 Jul 1999 09:49:52 -0700 Message-Id: <199907301649.JAA14668@finney.org> To: hal@finney.org, sven@krypt1.cs.uni-sb.de Subject: Re: typo in rfc2440: secret key packet format Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Sven Wohlgemuth, <sven@krypt1.cs.uni-sb.de>, writes: > Has a string-to-key specifier to follow the specification of the symmetric > algorithm? It does, if there was a 255 and then the symmetric algorithm. It must not, if you just put in the symmetric algorithm and didn't put a 255 first. > Since I can use the MD5 hash value of the passphrase as a symmetric key. > Why should I write > 255, 1 > if I just want to use a symmetric algorithm without a s2k-specifier? You don't have to. > > >> - One octet indicating string-to-key usage conventions. 0 > >> indicates that the secret key data is not encrypted. 255 > >> indicates that a string-to-key specifier is being given. Any > === > >> other value is a symmetric-key encryption algorithm specifier. > ============================================================= > Isn't it possible to write > 1, enc_MPI, ... > 1 for the sym. algorithm follwed by the encrypted MPIs, instead? Almost. There needs to be an IV before the encrypted MPIs start. The idea is that there are three formats. Unencrypted looks like: 0, MPI, ... The simpler encrypted case is similar to your last suggestion: <symmetric-alg>, <IV>, enc_MPI, ... This uses the default "simple" string-to-key conventions. The more complex one is: 255, <symmetric-alg>, <string-to-key>, <IV>, enc_MPI, ... This allows you to specify a different string to key specifier. That is the reason for the more complex format. The iterated/salted string-to-key is superior as it makes it harder to guess passphrases for someone who gets hold of the private key. Hal Finney Received: by mail.proper.com (8.9.3/8.9.3) id FAA07595 for ietf-open-pgp-bks; Fri, 30 Jul 1999 05:42:11 -0700 (PDT) Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA07591 for <ietf-open-pgp@imc.org>; Fri, 30 Jul 1999 05:42:00 -0700 (PDT) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.9.3/1999070600) with ESMTP id OAA07908; Fri, 30 Jul 1999 14:44:04 +0200 (CEST) Received: from krypt1.cs.uni-sb.de (krypt1.cs.uni-sb.de [134.96.243.153]) by cs.uni-sb.de (8.9.3/1999031900) with ESMTP id OAA13107; Fri, 30 Jul 1999 14:44:04 +0200 (CEST) Received: from [134.96.243.162] (krypt1 [134.96.243.153]) by krypt1.cs.uni-sb.de (8.8.8+Sun/8.8.8) with ESMTP id OAA13982; Fri, 30 Jul 1999 14:44:02 +0200 (MET DST) Date: Fri, 30 Jul 1999 14:44:02 +0200 (MET DST) X-Sender: sven@localhost Message-Id: <v03130306b3c7666dc12c@[134.96.243.162]> In-Reply-To: <199907281531.IAA09778@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hal@finney.org From: Sven Wohlgemuth <sven@krypt1.cs.uni-sb.de> Subject: Re: typo in rfc2440: secret key packet format Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Hello, thank you for your mail. But I have another question. At 8:31 Uhr -0700 28.07.1999, hal@finney.org wrote: >Sven Wohlgemuth, <sven@krypt1.cs.uni-sb.de>, writes: >> is there a typo in the following section? >> >> 5.5.3. Secret Key Packet Formats >> >> The Secret Key and Secret Subkey packets contain all the data of the >> Public Key and Public Subkey packets, with additional algorithm- >> specific secret key data appended, in encrypted form. >> >> The packet contains: >> >> - A Public Key or Public Subkey packet, as described above >> >> - One octet indicating string-to-key usage conventions. 0 >> indicates that the secret key data is not encrypted. 255 >> indicates that a string-to-key specifier is being given. Any >> other value is a symmetric-key encryption algorithm specifier. >> >> - [Optional] If string-to-key usage octet was 255, an one-octet >> =========== >> symmetric encryption algorithm. >> >> should it be replaced by "was between 0 and 255"? >> Since a symmetric encryption algorithm specifier is given only if the >> preceding value is between 0 and 255. >> Am I right? > >No, if the value is between 0 and 255 then that value is the symmetric >key algorithm specifier. So if the value is, say, 1, that means to use >symmetric algorithm 1. If the value is 255, then the *next* octet holds >the algorithm specifier. > >If you see: > 1 >then you use algorithm 1. > >If you see: > 255, 1 >then you use algorithm 1, and thyis is followed by the string-to-key >specifier. Has a string-to-key specifier to follow the specification of the symmetric algorithm? Since I can use the MD5 hash value of the passphrase as a symmetric key. Why should I write 255, 1 if I just want to use a symmetric algorithm without a s2k-specifier? >> - One octet indicating string-to-key usage conventions. 0 >> indicates that the secret key data is not encrypted. 255 >> indicates that a string-to-key specifier is being given. Any === >> other value is a symmetric-key encryption algorithm specifier. ============================================================= Isn't it possible to write 1, enc_MPI, ... 1 for the sym. algorithm follwed by the encrypted MPIs, instead? Thank you for your help! Regards, Sven Wohlgemuth Sven Wohlgemuth, Department 14, Computer Science, University of Saarbruecken, Germany, <http://fsinfo.cs.uni-sb.de/~wohlgemuth>, PGP-Fingerprints: RSA: 46C3 B9EB B21D EAAF 63C7 D667 F040 88A7 DSS: 56F0 55A2 4DF8 53C1 1E0E 52CB E196 5D18 894F 7C23 Received: by mail.proper.com (8.9.3/8.9.3) id IAA07711 for ietf-open-pgp-bks; Wed, 28 Jul 1999 08:26:57 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA07707 for <ietf-open-pgp@imc.org>; Wed, 28 Jul 1999 08:26:55 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id IAA09778; Wed, 28 Jul 1999 08:31:10 -0700 Date: Wed, 28 Jul 1999 08:31:10 -0700 Message-Id: <199907281531.IAA09778@finney.org> To: ietf-open-pgp@imc.org, sven@krypt1.cs.uni-sb.de Subject: Re: typo in rfc2440: secret key packet format Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Sven Wohlgemuth, <sven@krypt1.cs.uni-sb.de>, writes: > is there a typo in the following section? > > 5.5.3. Secret Key Packet Formats > > The Secret Key and Secret Subkey packets contain all the data of the > Public Key and Public Subkey packets, with additional algorithm- > specific secret key data appended, in encrypted form. > > The packet contains: > > - A Public Key or Public Subkey packet, as described above > > - One octet indicating string-to-key usage conventions. 0 > indicates that the secret key data is not encrypted. 255 > indicates that a string-to-key specifier is being given. Any > other value is a symmetric-key encryption algorithm specifier. > > - [Optional] If string-to-key usage octet was 255, an one-octet > =========== > symmetric encryption algorithm. > > should it be replaced by "was between 0 and 255"? > Since a symmetric encryption algorithm specifier is given only if the > preceding value is between 0 and 255. > Am I right? No, if the value is between 0 and 255 then that value is the symmetric key algorithm specifier. So if the value is, say, 1, that means to use symmetric algorithm 1. If the value is 255, then the *next* octet holds the algorithm specifier. If you see: 1 then you use algorithm 1. If you see: 255, 1 then you use algorithm 1, and thyis is followed by the string-to-key specifier. Hal Finney Network Associates Received: by mail.proper.com (8.9.3/8.9.3) id CAA14904 for ietf-open-pgp-bks; Wed, 28 Jul 1999 02:33:25 -0700 (PDT) Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA14889 for <ietf-open-pgp@imc.org>; Wed, 28 Jul 1999 02:33:15 -0700 (PDT) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.9.3/1999070600) with ESMTP id LAA26735 for <ietf-open-pgp@imc.org>; Wed, 28 Jul 1999 11:35:33 +0200 (CEST) Received: from krypt1.cs.uni-sb.de (krypt1.cs.uni-sb.de [134.96.243.153]) by cs.uni-sb.de (8.9.3/1999031900) with ESMTP id LAA15766 for <ietf-open-pgp@imc.org>; Wed, 28 Jul 1999 11:35:32 +0200 (CEST) Received: from krypt6 (krypt6 [134.96.243.158]) by krypt1.cs.uni-sb.de (8.8.8+Sun/8.8.8) with SMTP id LAA04983 for <ietf-open-pgp@imc.org>; Wed, 28 Jul 1999 11:35:31 +0200 (MET DST) Date: Wed, 28 Jul 1999 11:35:31 +0200 (MET DST) From: Sven Wohlgemuth <sven@krypt1.cs.uni-sb.de> X-Sender: sven@krypt6 To: ietf-open-pgp@imc.org Subject: typo in rfc2440: secret key packet format Message-ID: <Pine.GSO.3.96.990728112934.1251F-100000@krypt6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Hello, is there a typo in the following section? 5.5.3. Secret Key Packet Formats The Secret Key and Secret Subkey packets contain all the data of the Public Key and Public Subkey packets, with additional algorithm- specific secret key data appended, in encrypted form. The packet contains: - A Public Key or Public Subkey packet, as described above - One octet indicating string-to-key usage conventions. 0 indicates that the secret key data is not encrypted. 255 indicates that a string-to-key specifier is being given. Any other value is a symmetric-key encryption algorithm specifier. - [Optional] If string-to-key usage octet was 255, an one-octet =========== symmetric encryption algorithm. should it be replaced by "was between 0 and 255"? Since a symmetric encryption algorithm specifier is given only if the preceding value is between 0 and 255. Am I right? Regards, Sven Wohlgemuth Sven Wohlgemuth, department 14, computer science, University of Saarbruecken, Germany, < http://fsinfo.cs.uni-sb.de/~wohlgemuth >, PGP-Fingerprints: RSA: 46C3 B9EB B21D EAAF 63C7 D667 F040 88A7 DSS: 56F0 55A2 4DF8 53C1 1E0E 52CB E196 5D18 894F 7C23 Received: by mail.proper.com (8.9.3/8.9.3) id MAA29930 for ietf-open-pgp-bks; Tue, 27 Jul 1999 12:11:10 -0700 (PDT) Received: from mu.egroups.com (mu.egroups.com [207.138.41.151]) by mail.proper.com (8.9.3/8.9.3) with SMTP id MAA29926 for <ietf-open-pgp@imc.org>; Tue, 27 Jul 1999 12:11:08 -0700 (PDT) From: pianoman36@yougotemail.com Received: from [10.1.2.16] by mu.egroups.com with NNFMP; 27 Jul 1999 20:12:20 -0000 Date: Tue, 27 Jul 1999 12:12:13 -0700 To: ietf-open-pgp@imc.org Subject: newsgroups - privacy-HELP!!!!!!! Message-ID: <7nl0ad$77dj@eGroups.com> User-Agent: eGroups-EW/0.76 X-Mailer: www.eGroups.com Message Poster Sender: owner-ietf-open-pgp@imc.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Can anyone HELP. My email address had been posted to some obscene newsgroups and I would like to get it off. I looked up my name on dejanews and found that everyone could read things posted to my hotmail account and to the newsgroups. things are being posted to the hotmail acct that I I have not used since july 98. apparently they are signing my name and typing obscene things with my phnoe number. also my email addres has been posted to degrading and obscene newsgroups. Can ANYONE help me - what do I need to do to get this cleared up. Received: by mail.proper.com (8.9.3/8.9.3) id JAA28374 for ietf-open-pgp-bks; Tue, 27 Jul 1999 09:54:14 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA28369 for <ietf-open-pgp@imc.org>; Tue, 27 Jul 1999 09:54:10 -0700 (PDT) Received: from [129.46.222.63] (dhcp990305211402.qualcomm.com [129.46.222.63]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id JAA09816; Tue, 27 Jul 1999 09:56:02 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com (Unverified) Message-Id: <v04210102b3c38458449c@[129.46.222.63]> In-Reply-To: <Pine.GSO.4.02A.9907231235180.3709-100000@hardees.rutgers.edu> References: <Pine.GSO.4.02A.9907231235180.3709-100000@hardees.rutgers.edu> X-Mailer: Eudora [Macintosh version 4.2.1] 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: Tue, 27 Jul 1999 08:44:51 -0700 To: Tony Mione <mione@hardees.rutgers.edu> From: "John W. Noerenberg" <jwn2@qualcomm.com> Subject: Re: Oslo minutes? Cc: Dave Del Torto <ddt@lsd.com>, Werner Koch <wk@isil.d.shuttle.de>, ietf-open-pgp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-open-pgp@imc.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> At 12:36 PM -0400 7/23/99, Tony Mione wrote: > >Actually, I submitted the minutes to John Noerenberg by Friday of IETF week. Tony did a great job. The chair dallied. They are posted now. john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- The man that can most truly be accounted brave is he who best knows the meaning of what is sweet in life and what is terrible, and then goes out undeterred to meet what is to come. -- Pericles, "Funeral Oration", 479 B.C. ---------------------------------------------------------------------- Received: by mail.proper.com (8.9.3/8.9.3) id JAA28373 for ietf-open-pgp-bks; Tue, 27 Jul 1999 09:54:11 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA28360 for <ietf-open-pgp@imc.org>; Tue, 27 Jul 1999 09:54:04 -0700 (PDT) Received: from [129.46.222.63] (dhcp990305211402.qualcomm.com [129.46.222.63]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id JAA09799; Tue, 27 Jul 1999 09:55:59 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com (Unverified) Message-Id: <v04210101b3c384173557@[129.46.222.63]> In-Reply-To: <19990723155207.C5381@frodo.isil.d.shuttle.de> References: <19990723155207.C5381@frodo.isil.d.shuttle.de> X-Mailer: Eudora [Macintosh version 4.2.1] 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: Tue, 27 Jul 1999 08:44:00 -0700 To: Werner Koch <wk@isil.d.shuttle.de> From: "John W. Noerenberg" <jwn2@qualcomm.com> Subject: Re: Oslo minutes? Cc: ietf-open-pgp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-open-pgp@imc.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> At 3:52 PM +0200 7/23/99, Werner Koch wrote: > >are there any minutes from the Oslo meeting available or can someone >writeup a short summary? Werner, I sent the minutes to minutes@ietf.org, but neglected to send them to the list....<sigh> I've just posted them now. john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- The man that can most truly be accounted brave is he who best knows the meaning of what is sweet in life and what is terrible, and then goes out undeterred to meet what is to come. -- Pericles, "Funeral Oration", 479 B.C. ---------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id JAA28358 for ietf-open-pgp-bks; Tue, 27 Jul 1999 09:53:38 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA28354 for <ietf-open-pgp@imc.org>; Tue, 27 Jul 1999 09:53:36 -0700 (PDT) Received: from [129.46.222.63] (dhcp990305211402.qualcomm.com [129.46.222.63]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id JAA09788 for <ietf-open-pgp@imc.org>; Tue, 27 Jul 1999 09:55:58 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com (Unverified) Message-Id: <v04210100b3c383f72df4@[129.46.222.63]> X-Mailer: Eudora [Macintosh version 4.2.1] 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: Tue, 27 Jul 1999 08:42:59 -0700 To: OpenPGP mailing list <ietf-open-pgp@imc.org> From: "John W. Noerenberg" <jwn2@qualcomm.com> Subject: OpenPGP minutes Content-Type: multipart/alternative; boundary="============_-1279027935==_ma============" Sender: owner-ietf-open-pgp@imc.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> --============_-1279027935==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" OpenPGP - 45th IETF 14-July-1999 John Noerenberg opened the meeting at 9:05 AM. Started attendance list, etc. Agenda: Agenda Bashing Key Server Synchronization protocols RFC2440 Revisions Advance to Draft, Collect $200 RFC2015 Revisions Summary Agenda Bashing Key Server Synchronization protocols 2 Proposals Bill Geiger - Hash table exchange Marcel Waldvogel - Push-pull flooding Marcel Waldvogel thesis: <http://www.tik.ee.ethz.ch/tik/education/sadas/SASS1998-33/thesis.ps.gz> Bill Geiger: proposal introduction published in <http://www.imc.org/ietf-open-pgp/mail-archive/> in a messaged dated: Fri, 18 Jun 1999 09:43:36 -0500 JN: Key Server sync protocols are important. However, they are not in our charter. We need to decide whether to change the charter or create a new WG. JN recommended WG report to SAAG that a new working group should be explored for Key Server Synchronization protocols. After some discussion, there were no objections to this recommendation. RFC2440 Revisions JC: Need to decide what should be done to 2440 to get it ready for draft. Discussed some of the below. V5 Signatures Need to have larger signatures to accommodate the equivalent of certificates. Possible solution is to add up a 4 byte length. Only reason to hold off is to think about if anything else needs to change other than the length field format. [ Side conversation about closing off the group and leaving the fixes to a future group. JN: OpenPGP will exist until 2440 goes to Draft so we can go and fix this. In the interest of going to draft, the changes should be short at this time. MDC is clearly the most important.] MDC Data packet - Need a way to detect packet damage. Currently, a packet may be maliciously damaged by re-arranging blocks. Easiest way to fix this is to append a hash, preferably sha-1. Encryption Mode Normalization Features subpackets - This will provide a way for different PGPs to know what each other supports and what they do not. Gestalt for non-mandatory features Large Block ciphers clarifications Suggestions? Advance to Draft, Collect $200 6 months have passed Requirements 2 implementations No IPR problems 6 months of experience JN: We have the experience but we do not have the interoperability fully checked. Suggest: Enumerating all the musts and publishing a document so implementors can easily see requirements for compliance. Finally, we can get implementors into a room for testing. Implementors' survey & results are at: noc.rutgers.edu/~mione/ietf/ietfopgp.html IMC (Internet Mail Consortium) maintains the OpenPGP <http://www.imc.org/ietf-open-pgp/mail-archive/>mailing list archive. To subscribe and unsubscribe: List-subscribe: <mailto:ietf-open-pgp-request@imc.org?body=subscribe> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> RFC2015 Revisions Dave Del Torto 1 outstanding item: 'Openpgp signed data'. 2 variations were presented. Variation 1 is from Tom Rossler. Variation 2 is the original written by Dave Del Torto. The main difference is that variation 1 leaves out md5 as a required hash for the MICALG. The consensus seemed to be we should remove MUST for md5 hash in the MICALG. Discussion of parallel signatures. This is a way of dividing a message into multiparts and sign each individually. Allows you to verify signatures independently. (This text is in section 8 of the new draft to be submitted today.) The aim at this time is that parallel signatures will be OPTIONAL in the revision to 2015. Summary Misc question from audience. Will feature packets be a MUST implement. JC: No. Action items Jon Callas - New draft to replace 2440. Tony Mione - enumerate MUSTs in 2440. Dave, Thomas, Mike - New draft of 2015. WG as a whole - WG last call on Son of 2440. Son of 2015. before Nov. Tony tentatively volunteered to write a charter and call a bof for the PGP keysync work. John closed the meeting at 9:55 AM. Minutes submitted by Tony Mione john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- The man that can most truly be accounted brave is he who best knows the meaning of what is sweet in life and what is terrible, and then goes out undeterred to meet what is to come. -- Pericles, "Funeral Oration", 479 B.C. ---------------------------------------------------------------------- --============_-1279027935==_ma============ Content-Type: text/html; charset="us-ascii" <!doctype html public "-//W3C//DTD W3 HTML//EN"> <html><head><style type="text/css"><!-- blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 } --></style><title>OpenPGP minutes</title></head><body> <div><br></div> <div><br></div> <div><br> <x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab>OpenPGP - 45th IETF</div> <div><br> 14-July-1999<br> </div> <div>John Noerenberg opened the meeting at 9:05 AM. Started attendance list, etc.<br> <br> Agenda:<br> Agenda Bashing<br> Key Server Synchronization protocols<br> RFC2440 Revisions<br> Advance to Draft, Collect $200<br> RFC2015 Revisions<br> Summary<br> <br> <br> Agenda Bashing<br> <br> Key Server Synchronization protocols<br> <br> 2 Proposals<br> Bill Geiger - Hash table exchange</div> <div> Marcel Waldvogel - Push-pull flooding</div> <div> Marcel Waldvogel thesis:<br> <http://www.tik.ee.ethz.ch/tik/education<span ></span>/sadas/SASS1998-33/thesis.ps.gz><br> Bill Geiger: proposal introduction published in<br> <http://www.imc.org/ietf-open-pgp/mail-a<span ></span>rchive/></div> <div> in a messaged dated: Fri, 18 Jun 1999 09:43:36 -0500<br> <br> JN: Key Server sync protocols are important. However, they are not<br> in our charter. We need to decide whether to change the charter or<br> create a new WG.<br> <br> JN recommended WG report to SAAG that a new working group should be explored</div> <div> for Key Server Synchronization protocols. After some discussion, there were no<br> objections to this recommendation.<br> <br> RFC2440 Revisions<br> <br> JC: Need to decide what should be done to 2440 to get it ready for draft.<br> Discussed some of the below.<br> <br> V5 Signatures<br> </div> <div> Need to have larger signatures to accommodate the equivalent of<br> certificates. Possible solution is to add up a 4 byte length. Only<br> reason to hold off is to think about if anything else needs to<br> change other than the length field format.<br> <br> [ Side conversation about closing off the group and leaving the<br> fixes to a future group. JN: OpenPGP will exist until 2440 goes to<br> Draft so we can go and fix this. In the interest of going to draft,<br> the changes should be short at this time. MDC is clearly the most<br> important.]<br> <br> MDC Data packet - Need a way to detect packet damage. Currently, a<br> packet may be maliciously damaged by re-arranging blocks. Easiest</div> <div> way to fix this is to append a hash, preferably sha-1.<br> <br> Encryption Mode Normalization<br> </div> <div> Features subpackets - This will provide a way for different PGPs to<br> know what each other supports and what they do not.<br> <br> Gestalt for non-mandatory features<br> <br> Large Block ciphers clarifications<br> <br> Suggestions?<br> <br> Advance to Draft, Collect $200<br> 6 months have passed<br> Requirements<br> 2 implementations<br> No IPR problems<br> 6 months of experience<br> <br> JN: We have the experience but we do not have the interoperability<br> fully checked. Suggest: Enumerating all the musts and publishing a</div> <div> document so implementors can easily see requirements for</div> <div> compliance. Finally, we can get implementors into a room for<br> testing.<br> </div> <div> Implementors' survey & results are at:</div> <div> noc.rutgers.edu/~mione/ietf/ietfopgp.htm<span ></span>l<br> </div> <div> IMC (Internet Mail Consortium) maintains the OpenPGP <a href="http://www.imc.org/ietf-open-pgp/mail-archive/">mailing list archive</a>.</div> <div> To subscribe and unsubscribe:<br> List-subscribe: <mailto:ietf-open-pgp-request@imc.org?bo<span ></span>dy=subscribe><br> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?bo<span ></span>dy=unsubscribe><br> <br> <br> <br> RFC2015 Revisions<br> </div> <div> Dave Del Torto</div> <div> 1 outstanding item: 'Openpgp signed data'. 2 variations were<br> presented.</div> <div> Variation 1 is from Tom Rossler. Variation 2 is the original</div> <div> written by Dave Del Torto. The main difference is that variation<br> 1 leaves out md5 as a required hash for the MICALG.<br> </div> <div> The consensus seemed to be we should remove MUST for md5 hash in<br> the MICALG.<br> <br> Discussion of parallel signatures. This is a way of dividing a</div> <div> message into multiparts and sign each individually. Allows you to<br> verify signatures independently. (This text is in section 8 of the</div> <div> new draft to be submitted today.)<br> <br> The aim at this time is that parallel signatures will be OPTIONAL</div> <div> in the revision to 2015.</div> <div><br> Summary<br> </div> <div> Misc question from audience. Will feature packets be a MUST<br> implement. JC: No.<br> <br> Action items<br> Jon Callas - New draft to replace 2440.<br> <br> </div> <div> Tony Mione - enumerate MUSTs in 2440.</div> <div><br> Dave, Thomas, Mike - New draft of 2015.<br> <br> WG as a whole - WG last call on Son of 2440.<br> <span ></span > <span ></span > <span ></span> Son of 2015.<br> <span ></span > <span ></span> before Nov.</div> <div> Tony tentatively volunteered to write a charter and call a bof</div> <div > <span ></span > <span ></span > <span ></span> for the PGP keysync work.<br> <br> John closed the meeting at 9:55 AM.</div> <div><br></div> <div>Minutes submitted by Tony Mione</div> <div><br> john noerenberg<br> jwn2@qualcomm.com<br> ----------------------------------------<span ></span>------------------------------<br> The man that can most truly be accounted brave is he who best<br> knows the meaning of what is sweet in life and what is terrible,<br> and then goes out undeterred to meet what is to come.<br> -- Pericles, "Funeral Oration", 479 B.C.<br> ----------------------------------------<span ></span>------------------------------</div> </body> </html> --============_-1279027935==_ma============-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28088 for ietf-open-pgp-bks; Fri, 23 Jul 1999 09:34:38 -0700 (PDT) Received: from hardees.rutgers.edu (hardees.rutgers.edu [165.230.165.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28084 for <ietf-open-pgp@imc.org>; Fri, 23 Jul 1999 09:34:37 -0700 (PDT) Received: from localhost (mione@localhost) by hardees.rutgers.edu (8.8.8/8.8.8) with SMTP id MAA04360; Fri, 23 Jul 1999 12:36:07 -0400 (EDT) Date: Fri, 23 Jul 1999 12:36:07 -0400 (EDT) From: Tony Mione <mione@hardees.Rutgers.EDU> To: Dave Del Torto <ddt@lsd.com> cc: Werner Koch <wk@isil.d.shuttle.de>, ietf-open-pgp@imc.org Subject: Re: Oslo minutes? In-Reply-To: <v04210144b3be38aa34e2@[192.168.236.170]> Message-ID: <Pine.GSO.4.02A.9907231235180.3709-100000@hardees.rutgers.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> -----BEGIN PGP SIGNED MESSAGE----- Actually, I submitted the minutes to John Noerenberg by Friday of IETF week. Tony Mione, RUCS/TD, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650 mione@noc.rutgers.edu W3: http://noc.rutgers.edu/~mione/ PGPFP:D4EEA987E870277C 24AAE6E9E6ABD088 ***** Important: Rom 10:9-11 ***** Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR On Fri, 23 Jul 1999, Dave Del Torto wrote: > At 3:52 PM +0200 1999-07-23, Werner Koch wrote: > >are there any minutes from the Oslo meeting available or can someone > >writeup a short summary? > > Tony Mione has the minutes. > > dave > > -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by mkpgp2.1, a Pine/PGP interface. iQCVAwUBN5iZ6AfNcGHdn+zRAQF/PwQAvmaDlfSj7LElJwRkCjBfcJC2+KRji2J6 I+E1Woi9yC/N4JaOiQpxtV1DJhP6Hyehbp7VE2DguNpv+ZPqIzWY5rnClNsxKx9s i4BAb8kq3dg9UWqyqb18OBYIXmWJEYL/kqB5I+4G4YPMFUsmoDn7J1bFlJw5tUVY 35gA5rr5EYI= =IDHx -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA27347 for ietf-open-pgp-bks; Fri, 23 Jul 1999 08:28:50 -0700 (PDT) Received: from oscar1.circuit31.com (oscar.circuit31.com [208.225.230.140]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA27343 for <ietf-open-pgp@imc.org>; Fri, 23 Jul 1999 08:28:49 -0700 (PDT) Received: from dtsserver.circuit31.com by oscar1.circuit31.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 23 Jul 1999 15:30:51 UT Received: from [192.168.236.170] (192.168.236.170 [192.168.236.170]) by dtsserver.circuit31.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id PN3MVKZN; Fri, 23 Jul 1999 10:32:26 -0500 Mime-Version: 1.0 Message-Id: <v04210144b3be38aa34e2@[192.168.236.170]> In-Reply-To: <19990723155207.C5381@frodo.isil.d.shuttle.de> References: <19990723155207.C5381@frodo.isil.d.shuttle.de> Date: Fri, 23 Jul 1999 10:20:31 -0500 To: Werner Koch <wk@isil.d.shuttle.de> From: Dave Del Torto <ddt@lsd.com> Subject: Re: Oslo minutes? Cc: ietf-open-pgp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> At 3:52 PM +0200 1999-07-23, Werner Koch wrote: >are there any minutes from the Oslo meeting available or can someone >writeup a short summary? Tony Mione has the minutes. dave Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA26615 for ietf-open-pgp-bks; Fri, 23 Jul 1999 07:19:28 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA26611 for <ietf-open-pgp@imc.org>; Fri, 23 Jul 1999 07:19:25 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id QAA01570 for ietf-open-pgp@imc.org; Fri, 23 Jul 1999 16:21:22 +0200 (MET DST) Received: from (frodo.isil.d.shuttle.de) [172.20.1.4] (mail) by beren.isil.d.shuttle.de with esmtp (Exim 1.92 #1 (Debian)) id 117fog-00025O-00; Fri, 23 Jul 1999 15:56:50 +0200 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 2.05 #1 (Debian)) id 117fk7-0001PH-00; Fri, 23 Jul 1999 15:52:07 +0200 Date: Fri, 23 Jul 1999 15:52:07 +0200 From: Werner Koch <wk@isil.d.shuttle.de> To: ietf-open-pgp@imc.org Subject: Oslo minutes? Message-ID: <19990723155207.C5381@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i X-URL: http://www.openit.de/wks Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Hi, are there any minutes from the Oslo meeting available or can someone writeup a short summary? tia -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA11894 for ietf-open-pgp-bks; Thu, 22 Jul 1999 16:33:56 -0700 (PDT) Received: from dodo.prod.itd.earthlink.net (dodo.prod.itd.earthlink.net [207.217.120.99]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA11890; Thu, 22 Jul 1999 16:33:54 -0700 (PDT) Received: from AYMail (1Cust30.tnt1.oxnard.ca.da.uu.net [153.37.194.30]) by dodo.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id QAA24214; Thu, 22 Jul 1999 16:35:35 -0700 (PDT) Date: Thu, 22 Jul 1999 16:35:35 -0700 (PDT) Message-Id: <199907222335.QAA24214@dodo.prod.itd.earthlink.net> To: buzzine-private-list@dodo.prod.itd.earthlink.net From: buzzine-private-list@dodo.prod.itd.earthlink.net Subject: Withdrawl MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Hi, We were just notified that our purchased mail list included; imc-faxconnect@imc.org imc-faxconnect-request@imc.org imc-update-request@imc.org ietf@ietf.org ietf-822@imc.org ietf-822-request@imc.org ietf-conneg@imc.org ietf-fax@imc.org ietf-fax-request@imc.org ietf-medfree@imc.org ietf-open-pgp@imc.org ietf-request@ietf.org ietf-secretariat@ietf.org ifax-talk@ohnolab.org iesg@ietf.org iesg-secretary@ietf.org This is an error, and we have corrected the problem. If we can assist in any way by further checking our list please contact me directly. Thanks, Aaron BUZZINE.com Music & Entertainment ---------------------------------------------------------- The website: http://www.buzzine.com Email corrections: http://www.buzzine.com/contact Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA11332 for ietf-open-pgp-bks; Thu, 22 Jul 1999 15:44:31 -0700 (PDT) Received: from dodo.prod.itd.earthlink.net (dodo.prod.itd.earthlink.net [207.217.120.99]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA11281; Thu, 22 Jul 1999 15:41:08 -0700 (PDT) Received: from AYMail (1Cust30.tnt1.oxnard.ca.da.uu.net [153.37.194.30]) by dodo.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id PAA25649; Thu, 22 Jul 1999 15:33:21 -0700 (PDT) Date: Thu, 22 Jul 1999 15:33:21 -0700 (PDT) Message-Id: <199907222233.PAA25649@dodo.prod.itd.earthlink.net> To: buzzine-private-list@dodo.prod.itd.earthlink.net From: buzzine-private-list@dodo.prod.itd.earthlink.net Subject: Buzzine Confirmation MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Hi, We have you listed as a FAX NOTIFY entry on our private email list. If this is incorrect, please let us know. Your email was not complete, and we don't want to add you if it was an error. Spam is bad, even if it's an error. Thanks, BUZZINE.com Music & Entertainment ---------------------------------------------------------- The website: http://www.buzzine.com Email corrections: http://www.buzzine.com/contact Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA12326 for ietf-open-pgp-bks; Wed, 21 Jul 1999 19:21:45 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA12314 for <ietf-open-pgp@imc.org>; Wed, 21 Jul 1999 19:21:42 -0700 (PDT) Received: from [38.232.7.7] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 21 Jul 1999 18:24:05 -0800 Mime-Version: 1.0 X-Sender: jon@127.0.0.1 Message-Id: <v04210103b3bc2c4ddf5d@[10.5.63.113]> In-Reply-To: <19990721144302.A5564@nai.com> References: <Pine.GSO.4.02A.9907201636470.26697-100000@hardees.rutgers.edu> <m116vGy-0003b9C@ulf.mali.sub.org> <19990721123443.A5490@nai.com> <v04210109b3bbdf24e7e2@[10.5.63.113]> <19990721144302.A5564@nai.com> Date: Wed, 21 Jul 1999 19:03:56 -0700 To: Michael Elkins <Michael_Elkins@NAI.com>, ietf-open-pgp@imc.org From: Jon Callas <jon@callas.org> Subject: Re: OpenPGP conformance : MUSTS found in RFC2440 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> At 2:43 PM -0700 7/21/99, Michael Elkins said: Given that whether or not an implementation decides to implement compression can affect its ability to interoperate, I think it would be better to have the stronger suggestion that it be implemented. Think "you SHOULD implement this unless you know what you are doing and can accept the fact that your implementation will likely not interoperate." [...] I beleive it should be since the decision to not support compression doesn't mean that you can just ignore the issue all together if you hope to talk to anyone else besides yourself. Noted. You're right. I'll make it be a SHOULD in 2.3 and put in some expository text, related to the things we've written here. Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA28860 for ietf-open-pgp-bks; Wed, 21 Jul 1999 15:38:21 -0700 (PDT) Received: from mail5.svr.pol.co.uk (mail5.svr.pol.co.uk [195.92.193.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA28856 for <ietf-open-pgp@imc.org>; Wed, 21 Jul 1999 15:38:20 -0700 (PDT) Received: from modem-112.gadolinium.dialup.pol.co.uk ([62.136.31.240] helo=server.cypherspace.org) by mail5.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 117523-0008QI-00; Wed, 21 Jul 1999 23:40:12 +0100 Received: (from adam@localhost) by server.cypherspace.org (8.8.3/8.6.12) id XAA28759; Wed, 21 Jul 1999 23:27:46 +0100 Date: Wed, 21 Jul 1999 23:27:46 +0100 Message-Id: <199907212227.XAA28759@server.cypherspace.org> To: Michael_Elkins@NAI.com CC: ietf-open-pgp@imc.org From: Adam Back <adam@cypherspace.org> In-reply-to: <19990721144302.A5564@nai.com> (message from Michael Elkins on Wed, 21 Jul 1999 14:43:02 -0700) Subject: compression & interoperability (Re: OpenPGP conformance : MUSTS found in RFC2440) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Michael Elkins wrote: > > The SHOULD in 9.3 is perhaps a bit problematic. If you implement > > compression, ZIP is the algorithm to implement. Perhaps this really > > means that the MAY in 2.3 ought to be a SHOULD, and just be done with > > it. That's certainly the easiest change to make. The more I think > > about this as I write this note, I think that's the correct change to > > make -- MAY in 2.3 becomes SHOULD. > > Given that whether or not an implementation decides to implement compression > can affect its ability to interoperate, I think it would be better to have > the stronger suggestion that it be implemented. Think "you SHOULD implement > this unless you know what you are doing and can accept the fact that your > implementation will likely not interoperate." Couldn't something be done about this with a capability in the public key? ie as with mixmaster you don't send people compressed messages if they can't decompress them. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27660 for ietf-open-pgp-bks; Wed, 21 Jul 1999 14:44:36 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27653 for <ietf-open-pgp@imc.org>; Wed, 21 Jul 1999 14:44:33 -0700 (PDT) Received: from [10.5.63.113] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 21 Jul 1999 13:46:54 -0800 Mime-Version: 1.0 X-Sender: jon@127.0.0.1 Message-Id: <v0421010bb3bbedac5436@[10.5.63.113]> Date: Wed, 21 Jul 1999 14:46:25 -0700 To: ietf-open-pgp@imc.org From: Jon Callas <jon@callas.org> Subject: Error in 5.2.3.22 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> In OpenPGP, any signature may be revoked. In addition, there is a special "key revocation" signature that can be used to render the whole key inactive. 5.2.3.22 says this subpacket is only valid for key and certification revocations. I think it's useful to be able to put a reason on *any* signature revocation, and that this is an omission. For generic signatures, I can't think of a reason other than 0x00 (no reason specified) to be pertinent. But I think it should be allowed. Another question: Should this subpacket be elevated to SHOULD-implement? I want to keep as few SHOULDs and MUSTs as possible, but think this is an important feature. This subpacket, properly done, allows for keys to be retired, user names retired, and comments to be put on revocations. These are all so useful, I'd like to encourage implementers to do it. Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27535 for ietf-open-pgp-bks; Wed, 21 Jul 1999 14:42:24 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27531 for <ietf-open-pgp@imc.org>; Wed, 21 Jul 1999 14:42:21 -0700 (PDT) Received: from [10.5.63.113] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 21 Jul 1999 13:44:42 -0800 Mime-Version: 1.0 X-Sender: jon@127.0.0.1 Message-Id: <v0421010ab3bbe63c9399@[10.5.63.113]> Date: Wed, 21 Jul 1999 14:35:38 -0700 To: ietf-open-pgp@imc.org From: Jon Callas <jon@callas.org> Subject: Preference Conformance Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> There are also some conformance issues with all the preferences. An implementation SHOULD implement the preferences, but even if they don't, there is expected behavior. A compliant application has to do some right thing with all the preferences. The biggest one is the symmetric algorithm preferences. An application has to pick an algorithm from the recipient(s) collective allowable algorithms. Since 3DES is MUST-implement, it's the fallback algorithm. I know that some implementations don't do this; they pick one of the sender's preferred algorithms. I can think of a few cases that need to be tested: (1) Make a key that supports "only" (say) Blowfish. Verify that an implementation uses either Blowfish or 3DES (since 3DES is always implicitly permissible -- this is why I put "only" in quotes. You can't have a key that literally only supports Blowfish, but you know what I mean for these testing purposes). Do the same with 3DES, and verify that they use 3DES. (2) Verify that the implementation treats no preference packet as a preference for 3DES. (3) Create a key that supports only CAST. Encrypt a message to both it and the above key that supports only Blowfish. Verify that the implementation uses 3DES. Note that the minimal implementation doesn't implement this preference, and only implements 3DES. It passes all the above tests by always using 3DES. There's some similar testing that needs to be done for compression. Verify that a key with a no-compress preference doesn't get compressed to. Verify that the implementation doesn't use ZLIB unless it's in the recipient's preference allows it. This preference is different from the others in that if it is NOT present, it means you speak ZIP. As I said in the previous message, a minimal implementation that does not implement compression has to implement the preference. Sigh. I'm thinking more about this. MUST all implementations do the compression pref at least to the point of recognizing when not to compress? It looks like it to me. No testing needs to be done for preferred hash algorithms. Typically, a signer doesn't know who is going to verify a signature. This preference is there so that a protocol built on top of OpenPGP can say useful things to its partner. Similarly, there's not much testing that we can do for key server preferences in 2440 conformance. The implementations SHOULD allow a user to set them up. The key server itself, though, acts on the preferences. Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27489 for ietf-open-pgp-bks; Wed, 21 Jul 1999 14:39:08 -0700 (PDT) Received: from relay.nai.com (relay.nai.com [208.228.228.61]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27485 for <ietf-open-pgp@imc.org>; Wed, 21 Jul 1999 14:39:07 -0700 (PDT) Received: from dns-83-187.dhcp.nai.com (dns-83-187.dhcp.nai.com [161.69.83.187]) by relay.nai.com (8.9.3/8.9.3) with ESMTP id OAA25450 for <ietf-open-pgp@imc.org>; Wed, 21 Jul 1999 14:40:30 -0700 (PDT) Received: (from michael@localhost) by dns-83-187.dhcp.nai.com (8.8.7/8.8.7) id OAA05568 for ietf-open-pgp@imc.org; Wed, 21 Jul 1999 14:43:02 -0700 Message-ID: <19990721144302.A5564@nai.com> Date: Wed, 21 Jul 1999 14:43:02 -0700 From: Michael Elkins <Michael_Elkins@NAI.com> To: ietf-open-pgp@imc.org Subject: Re: OpenPGP conformance : MUSTS found in RFC2440 Mail-Followup-To: ietf-open-pgp@imc.org References: <Pine.GSO.4.02A.9907201636470.26697-100000@hardees.rutgers.edu> <m116vGy-0003b9C@ulf.mali.sub.org> <19990721123443.A5490@nai.com> <v04210109b3bbdf24e7e2@[10.5.63.113]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <v04210109b3bbdf24e7e2@[10.5.63.113]>; from Jon Callas on Wed, Jul 21, 1999 at 02:03:46PM -0700 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> On Wed, Jul 21, 1999 at 02:03:46PM -0700, Jon Callas wrote: > I think that the wording in 2.3 (MAY) is correct. We don't want to > say SHOULD, I don't think. It is usual, common practice, to compress > messages. I personally encourage implementers to compress, but at > something with a little less volume than SHOULD. Certainly, it is > good practice to compress, and your user community will scream bloody > murder if you don't. But is SHOULD the right word? It's always seemed > a little too strong to me, because I want to allow my mythical > encrypted pager network to not implement compression. > The SHOULD in 9.3 is perhaps a bit problematic. If you implement > compression, ZIP is the algorithm to implement. Perhaps this really > means that the MAY in 2.3 ought to be a SHOULD, and just be done with > it. That's certainly the easiest change to make. The more I think > about this as I write this note, I think that's the correct change to > make -- MAY in 2.3 becomes SHOULD. Given that whether or not an implementation decides to implement compression can affect its ability to interoperate, I think it would be better to have the stronger suggestion that it be implemented. Think "you SHOULD implement this unless you know what you are doing and can accept the fact that your implementation will likely not interoperate." > There's a related issue here, too, and that's dealing with the > compression preference. If you *don't* implement compression, you > have to start marking your certs with a compression preference that > says you don't speak compression. If you don't, people will send you > compressed messages that you can't uncompress. Should this be an > implementation note? I beleive it should be since the decision to not support compression doesn't mean that you can just ignore the issue all together if you hope to talk to anyone else besides yourself. me Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26866 for ietf-open-pgp-bks; Wed, 21 Jul 1999 14:12:41 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26861 for <ietf-open-pgp@imc.org>; Wed, 21 Jul 1999 14:12:37 -0700 (PDT) Received: from [10.5.63.113] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 21 Jul 1999 13:14:51 -0800 Mime-Version: 1.0 X-Sender: jon@127.0.0.1 Message-Id: <v04210109b3bbdf24e7e2@[10.5.63.113]> In-Reply-To: <19990721123443.A5490@nai.com> References: <Pine.GSO.4.02A.9907201636470.26697-100000@hardees.rutgers.edu> <m116vGy-0003b9C@ulf.mali.sub.org> <19990721123443.A5490@nai.com> Date: Wed, 21 Jul 1999 14:03:46 -0700 To: Michael Elkins <Michael_Elkins@NAI.com>, ietf-open-pgp@imc.org From: Jon Callas <jon@callas.org> Subject: Re: OpenPGP conformance : MUSTS found in RFC2440 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> At 12:34 PM -0700 7/21/1999, Michael Elkins said: It seems like this wording could lead to sever interoperability problems. Actually, though, that wording is there intentionally and carefully. PGP has, since Day 1, compressed. It's also supported not compressing, but it was something you had to manually turn on. It is desirable if the minimal PGP implementation could be built without putting in compression. Think pager. Consequently, that's the reason for the wording you'll find there. It's true (2.1) that PGP usually compresses. Always has, and arguably should in the vast majority of circumstances. (Although one could also argue that in some circumstances, like small messages, it's better not to compress. On the other other hand, you could also argue that compressing, even when the compressed data is bigger than uncompressed, has better security characteristics. But I'll bet you could also argue on the other other other hand that this is hooey.) This is really an issue for the developers, though. I think that the wording in 2.3 (MAY) is correct. We don't want to say SHOULD, I don't think. It is usual, common practice, to compress messages. I personally encourage implementers to compress, but at something with a little less volume than SHOULD. Certainly, it is good practice to compress, and your user community will scream bloody murder if you don't. But is SHOULD the right word? It's always seemed a little too strong to me, because I want to allow my mythical encrypted pager network to not implement compression. The SHOULD in 9.3 is perhaps a bit problematic. If you implement compression, ZIP is the algorithm to implement. Perhaps this really means that the MAY in 2.3 ought to be a SHOULD, and just be done with it. That's certainly the easiest change to make. The more I think about this as I write this note, I think that's the correct change to make -- MAY in 2.3 becomes SHOULD. There's a related issue here, too, and that's dealing with the compression preference. If you *don't* implement compression, you have to start marking your certs with a compression preference that says you don't speak compression. If you don't, people will send you compressed messages that you can't uncompress. Should this be an implementation note? Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA22619 for ietf-open-pgp-bks; Wed, 21 Jul 1999 12:30:50 -0700 (PDT) Received: from relay.nai.com (relay.nai.com [208.228.228.61]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA22611 for <ietf-open-pgp@imc.org>; Wed, 21 Jul 1999 12:30:49 -0700 (PDT) Received: from dns-83-187.dhcp.nai.com (dns-83-187.dhcp.nai.com [161.69.83.187]) by relay.nai.com (8.9.3/8.9.3) with ESMTP id MAA27117 for <ietf-open-pgp@imc.org>; Wed, 21 Jul 1999 12:32:11 -0700 (PDT) Received: (from michael@localhost) by dns-83-187.dhcp.nai.com (8.8.7/8.8.7) id MAA05502 for ietf-open-pgp@imc.org; Wed, 21 Jul 1999 12:34:43 -0700 Message-ID: <19990721123443.A5490@nai.com> Date: Wed, 21 Jul 1999 12:34:43 -0700 From: Michael Elkins <Michael_Elkins@NAI.com> To: ietf-open-pgp@imc.org Subject: Re: OpenPGP conformance : MUSTS found in RFC2440 Mail-Followup-To: ietf-open-pgp@imc.org References: <Pine.GSO.4.02A.9907201636470.26697-100000@hardees.rutgers.edu> <m116vGy-0003b9C@ulf.mali.sub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.93.2 In-Reply-To: =?iso-8859-1?Q?=3Cm116vGy-0003b9C=40ulf=2Emali=2Esub=2Eorg=3E=3B_from_Ul?= =?iso-8859-1?Q?f_M=F6ller_on_Wed=2C_Jul_21=2C_1999_at_02:14:00PM_+0200?= Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> On Wed, Jul 21, 1999 at 02:14:00PM +0200, Ulf Möller wrote: > There are contradictions in the RFC: Compression also has some problems. Section 2.1 ("Confidentiality via Encryption") states that OpenPGP encrypted messages are usually compressed. Section 2.3 ("Compression") states that implementations MAY compress a message after applying a signature. Section 9.3 ("Compression Algorithms") states that an implementation MUST support the type 0 (uncompressed data) algorithm and SHOULD support ZIP. It seems like this wording could lead to sever interoperability problems. me Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA15867 for ietf-open-pgp-bks; Wed, 21 Jul 1999 09:00:42 -0700 (PDT) Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA15852 for <ietf-open-pgp@imc.org>; Wed, 21 Jul 1999 09:00:30 -0700 (PDT) Received: from paris.public.uni-hamburg.de (max2-229.public.uni-hamburg.de [134.100.45.229]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id SAA60054; Wed, 21 Jul 1999 18:01:55 +0200 Received: by ulf.mali.sub.org (Smail3.1.28.1 #1) id m116vGy-0003b9C; Wed, 21 Jul 99 14:14 +0200 Message-Id: <m116vGy-0003b9C@ulf.mali.sub.org> Date: Wed, 21 Jul 99 14:14 +0200 From: ulf@fitug.de (Ulf =?iso-8859-1?Q?M=F6ller?=) To: mione@hardees.Rutgers.EDU Subject: Re: OpenPGP conformance : MUSTS found in RFC2440 Newsgroups: ulf.open-pgp In-Reply-To: <Pine.GSO.4.02A.9907201636470.26697-100000@hardees.rutgers.edu> Organization: HR13 Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> >I agreed to take on a couple of work items at the OpenPGP meeting in Oslo, >Norway. One of those work items was to enumerate the MUSTS in RFC2440 in >order to help vendors begin conformance testing. Just grepping for "MUST" won't get you anywhere. You missed important specifications like "An OpenPGP message is a packet or sequence of packets that corresponds to the following grammatical rules" (10.2) and the key format requirements. On the other hand, some MUSTs just describe facts where there are no possible choices on the implementor's side and one might as well write "the octet is 5", "the packet is ignored", "the flag is zero". But there are more problems to it. If you really want to take this task upon you, you'll have to do what the authors already should have done before publishing a standards track RFC: look at each feature the RFC describes and determine whether or not it is required for a minimal implementation. There are contradictions in the RFC: "Hashed subpacket data. (zero or more subpackets)" ^^^^ "Signature creation time [...] MUST be present in the hashed area." The issuer key ID subpacket is never specified as a required, but later on in the section "Subpacket Hints" the RFC mentions in passing: "An implementation SHOULD put the two mandatory subpackets, creation time and issuer, as the first subpackets". The RFC doesn't say anything about accepting V4 signatures. Much of the complexity of OpenPGP comes from the desire to be interoperable with PGP 2. But the RFC does not even mention that PGP 2 expects certain packet length types for certain packet types. Similarly, PGP 5 requires certain packet versions for certain signature types. This sort of thing ought to be described in an implementor's guide. By the way, you forgot "MUST implement Elgamal" in your list. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA15934 for ietf-open-pgp-bks; Tue, 20 Jul 1999 15:03:43 -0700 (PDT) Received: from hardees.rutgers.edu (hardees.rutgers.edu [165.230.165.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA15930 for <ietf-open-pgp@imc.org>; Tue, 20 Jul 1999 15:03:42 -0700 (PDT) Received: from localhost (mione@localhost) by hardees.rutgers.edu (8.8.8/8.8.8) with SMTP id SAA26363; Tue, 20 Jul 1999 18:05:27 -0400 (EDT) Date: Tue, 20 Jul 1999 18:05:27 -0400 (EDT) From: Tony Mione <mione@hardees.Rutgers.EDU> To: hal@finney.org cc: ietf-open-pgp@imc.org, mione@hardees.Rutgers.EDU Subject: Re: OpenPGP conformance : MUSTS found in RFC2440 In-Reply-To: <199907202145.OAA11505@finney.org> Message-ID: <Pine.GSO.4.02A.9907201749400.26697-100000@hardees.rutgers.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> -----BEGIN PGP SIGNED MESSAGE----- On Tue, 20 Jul 1999 hal@finney.org wrote: > Tony Mione, <mione@hardees.Rutgers.EDU>, writes: > > I agreed to take on a couple of work items at the OpenPGP meeting in Oslo, > > Norway. One of those work items was to enumerate the MUSTS in RFC2440 in > > order to help vendors begin conformance testing. > > > > Following is the list I came up with (anyone with some spare time, please > > check me on the list). I also plan on forwarding SHOULDS, MAYS, SHOULD > > NOTS, etc. hopefully within the next week. > > This is a good start, but just searching for occurances of MUST/SHOULD > in the document will not be enough to promote interoperability, in my > opinion. Unfortunately there are many sections where we do not clearly > describe which features must/should be supported. > I understand that. I was asked to do this by John Noerenberg as a starting point to help implementors. That is why I suggested adding the other lists and actually writing an informational RFC. I know that Jon Callas is interested in helping and I was told I could contact an NAI PGP developer (I think the name was Mike Elkins?) who would probably have a lot of good info to add. > For example, section 3.6.1 describes three kinds of string-to-key > specifiers. We do not say whether any of them must be supported. > In 3.6.2 we say implementations "SHOULD use" two of them. But I > think we meant that for creation purposes, and probably they should > also be able to read the third one. > > In section 4 we document packet headers, including a variety of packet > length specifiers. We do have some rules in 4.2.3 which put restrictions > on how they are used. But we do not say that you must or should support > all these packet length formats. Without supporting at least some of > them you won't be able to parse any OpenPGP messages. > > In section 5 we enumerate all the packet types. But we never say which > packets must or should be supported. > > We also describe ascii armor and clearsigning without clearly saying > whether these are MUST, SHOULD, or MAY. > > Overall there is much left unspecified about what is required and what > is not. I would suggest that all features documented are implicitly > SHOULD except when indicated otherwise. We documented them with the > intention that people would use these features, although in particular > circumstances an implementor can make the decision not to do so. That > seems compatible with the definition of SHOULD. > Thanks for the comments. I will collect all responses and take them into consideration as I am rereading RFC2440. > Hal Finney > Network Associates > Tony Mione, RUCS/TD, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650 mione@noc.rutgers.edu W3: http://noc.rutgers.edu/~mione/ PGPFP:D4EEA987E870277C 24AAE6E9E6ABD088 ***** Important: Rom 10:9-11 ***** Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by mkpgp2.1, a Pine/PGP interface. iQCVAwUBN5Tx2AfNcGHdn+zRAQFbRwQAs0zID6JTKFPafRcTz8jgYSwmqaHjg5fb BKRvrYEcTlly8edoiuZMPt0T/vEQilYROkUK5N9YlnaDEbF4iJvY8dQVmDzE/gfE 11etrbjF/U0OOTXC2YG8213C+aVwxgFH7Jko6gFiJsM3BPkDBsU29JetSbZD56Mk 5Iav0OSSR2c= =kj1m -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA15405 for ietf-open-pgp-bks; Tue, 20 Jul 1999 14:41:39 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA15401 for <ietf-open-pgp@imc.org>; Tue, 20 Jul 1999 14:41:38 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id OAA11505; Tue, 20 Jul 1999 14:45:17 -0700 Date: Tue, 20 Jul 1999 14:45:17 -0700 Message-Id: <199907202145.OAA11505@finney.org> To: ietf-open-pgp@imc.org, mione@hardees.Rutgers.EDU Subject: Re: OpenPGP conformance : MUSTS found in RFC2440 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Tony Mione, <mione@hardees.Rutgers.EDU>, writes: > I agreed to take on a couple of work items at the OpenPGP meeting in Oslo, > Norway. One of those work items was to enumerate the MUSTS in RFC2440 in > order to help vendors begin conformance testing. > > Following is the list I came up with (anyone with some spare time, please > check me on the list). I also plan on forwarding SHOULDS, MAYS, SHOULD > NOTS, etc. hopefully within the next week. This is a good start, but just searching for occurances of MUST/SHOULD in the document will not be enough to promote interoperability, in my opinion. Unfortunately there are many sections where we do not clearly describe which features must/should be supported. For example, section 3.6.1 describes three kinds of string-to-key specifiers. We do not say whether any of them must be supported. In 3.6.2 we say implementations "SHOULD use" two of them. But I think we meant that for creation purposes, and probably they should also be able to read the third one. In section 4 we document packet headers, including a variety of packet length specifiers. We do have some rules in 4.2.3 which put restrictions on how they are used. But we do not say that you must or should support all these packet length formats. Without supporting at least some of them you won't be able to parse any OpenPGP messages. In section 5 we enumerate all the packet types. But we never say which packets must or should be supported. We also describe ascii armor and clearsigning without clearly saying whether these are MUST, SHOULD, or MAY. Overall there is much left unspecified about what is required and what is not. I would suggest that all features documented are implicitly SHOULD except when indicated otherwise. We documented them with the intention that people would use these features, although in particular circumstances an implementor can make the decision not to do so. That seems compatible with the definition of SHOULD. Hal Finney Network Associates Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14286 for ietf-open-pgp-bks; Tue, 20 Jul 1999 14:07:23 -0700 (PDT) Received: from hardees.rutgers.edu (hardees.rutgers.edu [165.230.165.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14282 for <ietf-open-pgp@imc.org>; Tue, 20 Jul 1999 14:07:20 -0700 (PDT) Received: from localhost (mione@localhost) by hardees.rutgers.edu (8.8.8/8.8.8) with SMTP id RAA19656; Tue, 20 Jul 1999 17:09:08 -0400 (EDT) Date: Tue, 20 Jul 1999 17:09:08 -0400 (EDT) From: Tony Mione <mione@hardees.Rutgers.EDU> To: ietf-open-pgp@imc.org cc: Tony Mione <mione@hardees.Rutgers.EDU> Subject: OpenPGP conformance : MUSTS found in RFC2440 Message-ID: <Pine.GSO.4.02A.9907201636470.26697-100000@hardees.rutgers.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> -----BEGIN PGP SIGNED MESSAGE----- I agreed to take on a couple of work items at the OpenPGP meeting in Oslo, Norway. One of those work items was to enumerate the MUSTS in RFC2440 in order to help vendors begin conformance testing. Following is the list I came up with (anyone with some spare time, please check me on the list). I also plan on forwarding SHOULDS, MAYS, SHOULD NOTS, etc. hopefully within the next week. The discussion we had openned the possibility of grouping the lists together and adding a small amount of additional information. The result would be an informational RFC probably titled 'OpenPGP Implementor's Guide.' I am willing to do the bulk of the wordsmithing on the document and know of two other possible co-authors. Is there any interest in such a document? Anyway, Here are the MUSTS that I found. I have included section numbers from 2440 and a brief paraphrased description. For more information, read 2440. ===== OpenPGP MUSTS Section Summary of requirement - ------- ---------------------- 4.2.3 1st partial length MUST be at least 512 bytes long. 5.1 For multiple Public Key Encrypted Session Key packets, implementations MUST make new PKCS-1 padding for each key. 5.2 Implmenetations MUST accept V3 signatures. 5.2.2 1st octet length of hash material MUST be 5. in V3 signature packet. 5.2.2 DSA signatures MUST use hashes with a size of 160 bits to match q. The size of the groups generated by the DSA key's generator value. 5.2.3.3 The signature creation time sub-packet MUST be in the hashed area of a V4 signature packet. 5.2.3.15 In Notation Data subpacket all undefined flags in the flag field MUST be zero. 5.2.3.16 In key server preferences, all undefined flags MUST be zero. 5.3 The S2K specifier in a Symmentric Key Encrypted Session Key packet MUST be Salted or Iterated and Salted. since the IV is 0. This is to prevent identical decryption keys if a passphrase is re-used. 5.8 Marker packets (tag 10) MUST be ignored when received. 6.2 The Message Armor header 'MessageID' (if it appears) MUST be computed from the encrypted signed message in a deterministic fashion (rather than being random) to prevent covert channels. 9.1 MUST implement DSA for signatures. 9.2 MUST implement 3-DES for symmetric encryption. 9.3 MUST implement uncompressed data. 9.4 MUST implement SHA-1. 11.1 In keys with main keys and sub keys, the primary key MUST be capable of signing. 12.1 If an algorithm is used in encryption is not in the user's preference list, the implementation SHOULD decrypt anyway but MUST warn the user of the protocol violation. 12.4 Implementations supporting RSA in V4 keys MUST implement all MUST features from V4 key section. 12.5 If an implementation allows ELGammal signatures, then it MUST use the algorithm id 20 for an ElGammal public key that can sign. ===== Tony Mione, RUCS/TD, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650 mione@noc.rutgers.edu W3: http://noc.rutgers.edu/~mione/ PGPFP:D4EEA987E870277C 24AAE6E9E6ABD088 ***** Important: Rom 10:9-11 ***** Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by mkpgp2.1, a Pine/PGP interface. iQCVAwUBN5TlVAfNcGHdn+zRAQH8ZQQAnogLjUI/4ICOBXT8aLWbdkvjN9u6EKYp tFfu3CcCD22MGT8mPXM2XVdttfOAxhOhz967Zv1uubxljuMdM0/N1zOdV/FxvW0X cDM6Dz1QGaptGCZ9aCyIDN2jL3RAofT7hSiIITtuqHUk79p8G9BYbNVfZ4EFj+49 cmBuBQ199Mc= =0oOz -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA02687 for ietf-open-pgp-bks; Mon, 19 Jul 1999 06:56:13 -0700 (PDT) Received: from sina.tums.ac.ir ([194.225.91.46]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA02643 for <ietf-open-pgp@imc.org>; Mon, 19 Jul 1999 06:53:44 -0700 (PDT) Received: from remote-11.tums.ac.ir by sina.tums.ac.ir id aa28653; 19 Jul 99 18:23 IDT Message-ID: <001501bed1ee$050e56c0$04000005@pentiumc> From: Sayeh Sadat <sadat@sina.tums.ac.ir> To: spki@c2.net, ietf-pkix@tandem.com, ietf-open-pgp@imc.org MMDF-Warning: Parse error in original version of preceding line at sina.tums.ac.ir Subject: Request For help . Date: Mon, 19 Jul 1999 18:22:17 +0430 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01BED213.A23A64A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_0012_01BED213.A23A64A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sir/Madam , =20 I am writing to ask you for a help if possible . I study = communication electronics in " Sharif University Of Technology " of Iran = . My final project is about " Public Key Cryptography " and I am looking = for any kind of information relative to this topic . =20 Unfortunately , there is not enough source of information on this = subject in my country , Iran . So , could you please possibly send me = any relative information including articles , useful sites offering such = informations and other useful sources . =20 I would be very grateful if you help me . I am looking forward to = receiveing any information from you . =20 Yours Faithfully , --Sayeh Sadat-- =20 Sayeh Sadat , L.S. Sharif University Of Technology . Electrical Department . =20 Phone : 98-21-2547364 98-21-2549378 =20 Email : SADAT@SINA.TUMS.AC.IR ( Please use this one that is full = graphic ) SAADAAT@EE.SHARIF.AC.IR SAYEH_SADAT@IEEE.ORG SAYEH_SADAT@COMPUTER.ORG SAYEH_SADAT@HOTMAIL.COM Mail Address : =20 Sayeh Sadat 2ND FL #49 GHOLAMREZA RAHMANI ST. DIBAJI JONUBI ST. DOLAT AVE. 19598 TEHRAN=20 IRAN=20 ------=_NextPart_000_0012_01BED213.A23A64A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV> <DIV><FONT size=3D2>Dear Sir/Madam ,</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2> I am writing to = ask you for a=20 help if possible . </FONT><FONT color=3D#000000 size=3D2>I study = communication=20 electronics in " Sharif University Of Technology " of Iran .=20 </FONT><FONT color=3D#000000 size=3D2>My final project is about "=20 <STRONG><EM><U>Public Key Cryptography</U></EM></STRONG> " and I am = looking=20 for any kind of information relative to this topic .</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2> Unfortunately , = there is not=20 enough source of information on this subject in my country , Iran . = </FONT><FONT=20 color=3D#000000 size=3D2>So , could you please possibly send me any = relative=20 information including articles , useful sites offering such informations = and=20 other useful sources .</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2> I would be very = grateful if=20 you help me . I am looking forward to receiveing any information from = you=20 .</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>Yours Faithfully ,</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2> --Sayeh Sadat--</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT size=3D2>Sayeh</FONT> <FONT size=3D2>Sadat , = L.S.</FONT></DIV> <DIV><FONT size=3D2>Sharif</FONT> <FONT size=3D2>University</FONT> <FONT = size=3D2>Of</FONT> <FONT size=3D2>Technology .</FONT></DIV> <DIV><FONT size=3D2>Electrical </FONT><FONT size=3D2>Department = .</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>Phone :</FONT></DIV> <DIV><FONT=20 size=3D2> &nbs= p;=20 </FONT><FONT size=3D2>98-</FONT><FONT size=3D2>21-</FONT><FONT=20 size=3D2>2547364</FONT></DIV> <DIV> <FONT color=3D#000000=20 size=3D2> =20 98-21-2549378</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT><FONT = size=3D2></FONT> </DIV> <DIV><FONT size=3D2>Email :</FONT></DIV> <DIV><FONT = size=3D2> =20 <A href=3D"mailto:SADAT@SINA.TUMS.AC.IR">SADAT@SINA.TUMS.AC.IR</A> ( = Please use=20 this one that is full graphic )</FONT></DIV> <DIV><FONT size=3D2></FONT><FONT color=3D#000000=20 size=3D2> <A = href=3D"mailto:SAADAAT@EE.SHARIF.AC.IR">SAADAAT@EE.SHARIF.AC.IR</A></FONT= ></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> <DIV><FONT = size=3D2> =20 <A = href=3D"mailto:SAYEH_SADAT@IEEE.ORG">SAYEH_SADAT@IEEE.ORG</A></FONT></DIV= > <DIV><FONT = size=3D2> =20 <A=20 href=3D"mailto:SAYEH_SADAT@COMPUTER.ORG">SAYEH_SADAT@COMPUTER.ORG</A></FO= NT></DIV></DIV> <DIV><FONT color=3D#000000=20 size=3D2> <A = href=3D"mailto:SAYEH_SADAT@HOTMAIL.COM">SAYEH_SADAT@HOTMAIL.COM</A></FONT= ></DIV> <DIV> </DIV> <DIV><FONT color=3D#000000 size=3D2>Mail Address=20 : </FONT></DIV> <DIV><FONT color=3D#000000=20 size=3D2> = Sayeh=20 Sadat</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT><FONT=20 size=3D2> = 2ND FL=20 #49</FONT></DIV> <DIV><FONT = size=3D2> =20 GHOLAMREZA RAHMANI ST.</FONT></DIV> <DIV><FONT = size=3D2> =20 DIBAJI JONUBI ST.</FONT></DIV> <DIV><FONT = size=3D2> =20 DOLAT AVE.</FONT></DIV> <DIV><FONT = size=3D2> =20 19598 TEHRAN </FONT></DIV> <DIV><FONT size=3D2></FONT><FONT=20 size=3D2> =20 IRAN </FONT></DIV> <DIV><BR></DIV></DIV></BODY></HTML> ------=_NextPart_000_0012_01BED213.A23A64A0-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24582 for ietf-open-pgp-bks; Wed, 14 Jul 1999 07:15:06 -0700 (PDT) Received: from barbar.esat.kuleuven.ac.be (root@barbar.esat.kuleuven.ac.be [134.58.56.153]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24215; Wed, 14 Jul 1999 07:09:55 -0700 (PDT) Received: from domein.esat.kuleuven.ac.be (cms99@domein.esat.kuleuven.ac.be [134.58.189.69]) by barbar (version 8.8.5) with ESMTP id QAA04539; Wed, 14 Jul 1999 16:10:32 +0200 (METDST) Organization: ESAT, K.U.Leuven, Belgium Date: Wed, 14 Jul 1999 16:10:30 +0200 (METDST) From: "CMS'99" <cms99@esat.kuleuven.ac.be> To: Communications and Multimedia Security 1999 <cms99@esat.kuleuven.ac.be> Subject: CMS'99 - Communications and Multimedia Security Message-ID: <Pine.HPX.4.05.9907141551170.8153-100000@domein.esat.kuleuven.ac.be> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.proper.com id HAA24220 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> [apologies if you receive this mail multiple times] Communications and Multimedia Security is a joint working conference of IFIP TC6 and TC11. CMS'99 will be organized September 20-21, 1999 at the Katholieke Universiteit Leuven, Belgium. On-line registration can be done at http://www.esat.kuleuven.ac.be/cosic/cms99/ Reduced fee of 250 EURO until August 1, 1999. Draft program: ----------------------------------------------------------------------- Monday, September 20 8u00-8u45 Registration 8u45-9u00 Welcome 9u00-10u30 Network security: ATM and ISDN Security On ATM Networks Stelios Karanastasis, Ahmed Patel ISDN Security Services Herbert Leitold, Karl Christian Posch, Reinhard Posch An Alternative Access Control Architecture for IP over ATM Networks Olivier Paul, Maryline Laurent 10u30-10u50 Coffee 10u50-11u50 Applied Cryptology I Verifiable Democracy Yvo Desmedt, Brian King Efficient Oblivious Proofs of Correct Exponentiation Markus Jakobsson, Claus Peter Schnorr 11u50-13u30 Lunch 13u30-14u30 Invited talk (to be announced) 14u30-15u30 Entity Authentication and Key Agreement Protocols Weaknesses in EHA Authentication and Key Distribution Protocol Martin Stanek, Daniel Olejár Formal Design of Efficient Authentication and Key-Agreement Protocols Gunnar Jacobson 15u30-16u00 Coffee 16u00-17u30 Network security: IP Protecting Key Exchange and Management Protocols Against Resource Clogging Attacks Rolf Oppliger Secured Distributed Virtual Conferencing W.A. Adamson, C.J. Antonelli, K.W. Coffman, P. McDaniel, J. Rees PIM-SM Security: Interdomain Issues and Solutions Thomas Hardjono, Brad Cain 17u30-18u00 Recent results 19u30 Banquet Tuesday, September 21 8:30-10u00 Protocols for Mobile Applications Attacks against the WAP WTLS protocol Markku-Juhani Saarinen A New Authentication Protocol for Portable Communication Systems Sheng-bo Xu, Cees Jansen, Henk van Tilborg Token Based Authentication for Handover Security Yi Cheng, Arne Norefors 10u00-10u30 Coffee Break 10u30-12u00 Applications On Authentication, Digital Signatures and Signature Laws Per Kaijser Watermarking and Secure Distribution for Encrypted Video T. Amornraksa, D.R.B. Burgess, P. Sweeney Implementing a Secure Log File Download Manager for the Java Card Constantinos Markantonakis, Simeon Xenitellis 12u00-14u00 Lunch 14u00-15u30 Applied Cryptology II How to Securely Broadcast a Secret Jörg Schwenk Proofs of Work and Bread Pudding Protocols Markus Jakobsson, Ari Juels Attack on Liu/Farrel/Boyd Arithmetic Coding Encryption Scheme Takeyuki Uehara, Reihaneh Safavi-Naini 15u30-16u00 Coffee 16u00-17u00 Web security Secure Data-Transfer for Web-Based Applications Wolfgang Platzer Using SESAME to Secure Web Based Applications on an Intranet Paul Ashley, Mark Vandenwauver, Joris Claessens ----------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA05536 for ietf-open-pgp-bks; Tue, 13 Jul 1999 23:03:03 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA05532 for <ietf-open-pgp@imc.org>; Tue, 13 Jul 1999 23:03:02 -0700 (PDT) Received: from [128.39.29.73] (xing.qualcomm.com [129.46.2.42]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id XAA21056; Tue, 13 Jul 1999 23:04:04 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@127.0.0.1 (Unverified) Message-Id: <v04210100b3b19d03247c@[128.39.31.93]> In-Reply-To: <378334DE.119ADA3E@cyphers.net> References: <19990707111435.B28643@sobolev.rhein.de> <37831FF6.AB95A116@cyphers.net> <19990707122008.B1329@sobolev.rhein.de> <378334DE.119ADA3E@cyphers.net> X-Mailer: Eudora [Macintosh version 4.2.1] 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: Wed, 14 Jul 1999 04:09:57 +0200 To: Will Price <wprice@cyphers.net> From: "John W. Noerenberg" <jwn2@qualcomm.com> Subject: Re: PGP 6.5.1 - word list and SDAs? Cc: ietf-open-pgp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> At 4:07 AM -0700 7/7/99, Will Price wrote: > >Thomas Roessler wrote: > > On 1999-07-07 02:38:43 -0700, Will Price wrote: >> > > >Yes, it was obvious. You're not seeing what I mean by biometric. >The word list is a feature we implemented to provide better biometric >properties for key fingerprint authentication. > > >> > Technical documentation and mappings for the word lists are >> > published in the docs for PGP where they belong. Not in this >> > group. >> >> Sorry, Will, this word mapping _is_ an interchange format for >> OpenPGP key properties, so it _does_ belong on this list and into >> an (at least informational) Internet RFC. After all, there is a >> reason behind having a well-defined key fingerprint displayed to >> and exchanged by users, isn't it? > >I could see a case for documenting the word list we developed into an >informational RFC with no relation to this working group. I'm sure >we'd be happy to see that happen. However, the feature is a >biometric authentication method that has no relation to the OpenPGP >data formats. Saying that this should have gone through OpenPGP in >the first place is like saying the PGPkeys GUI and whether RSA keys >are silver or gold should go through OpenPGP. There are interesting points here. If the word list is relied upon the the users of the application to exchange the fingerprint, then it is part of the protocol of key exchange. While RFC2440 doesn't deal with key exchange, we've assumed that key verification by users would be performed by exchanging fingerprints in some fashion. The word list is an example of "in some fashion", and must equate to the fingerprint, otherwise it wouldn't unambiguously identify a key. It is mandatory that any RFC2440 implementation generate and parse a particular kind of fingerprint. While the word list may prove to be eminently useful (it may not, I was amused by Thomas' notion of a "spoken" business card). It seems to me we can safely put this aside. It may become an issue, however, if work on key exchange protocols and experience with word lists indicates it will likely become widely accepted, and is a preferred way to express the fingerprint. For now, I'd prefer to leave it aside and concentrate on verifying the status in implementations of existing MUSTs in 2440. john noerenberg (in Oslo Jul 10-19, 1999) jwn2@qualcomm.com ---------------------------------------------------------------------- The man that can most truly be accounted brave is he who best knows the meaning of what is sweet in life and what is terrible, and then goes out undeterred to meet what is to come. -- Pericles, "Funeral Oration", 479 B.C. ---------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA23711 for ietf-open-pgp-bks; Mon, 12 Jul 1999 16:01:56 -0700 (PDT) Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA23706 for <ietf-open-pgp@imc.org>; Mon, 12 Jul 1999 16:01:54 -0700 (PDT) Received: from max1-025.public.uni-hamburg.de (max1-025.public.uni-hamburg.de [134.100.43.25]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id BAA40808 for <ietf-open-pgp@imc.org>; Tue, 13 Jul 1999 01:02:46 +0200 Received: id <m113n2a-000Qe9C@epsilon>; Mon, 12 Jul 1999 22:51:08 +0200 (CEST) Message-Id: <m113n2a-000Qe9C@epsilon> Date: Mon, 12 Jul 1999 22:51:08 +0200 (CEST) From: Bodo_Moeller@public.uni-hamburg.de (Bodo Moeller) To: ietf-open-pgp@imc.org Subject: Re: Key expiration In-Reply-To: <v04003a03b3af5d0deb7b@[0.0.0.0]> References: <19990709144402.A41480@public.uni-hamburg.de> <v04003a03b3af5d0deb7b@[0.0.0.0]> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Jon Callas <jon@callas.org>: > At 5:44 AM -0700 7/9/1999, Bodo Moeller said: > Me too. I did not detail this in my previous message, but IMO the way > to go is to use short validity periods on your encryption keys (so > that if you let them expire, no-one will send you mail encrypted to > those keys any more; an additional advantage is that you can change > the cipher preferences etc. if you switch to newer software versions) > and a longer validity period for the signing key. Also your signing > key could use a long _key_ validity period, but short _signature_ > validity periods for the self-signatures; then the key validity > period, if defined, should be used by others who certify that key. > A signing key is really invalid only when publishing its secret part > cannot break anything (not that I recommend doing so ...). > > > [...] > > The self-signature! Not the whole key, unless you don't re-validate. > For this, a signature validity period should be used, not a key > validity period. > We're in violent agreement here. > > The problem is that "key expiration" in OpenPGP (well, actually in the V4 > data structures) is in the self signature. If you look at the V3 key > packet, there's a key expiration. In the V4 structure, it is gone. It's in > the self-sig. That's what I wrote in my previous message, isn't it? The point here is that the self-signature can define _two_ validity periods: A key validity period (section 5.2.3.5), which should be evaluated by others when certifying the key so that an expired key is guaranteed to be considered invalid by those trusting the certficate, and a self-signature validity period (section 5.2.3.9), which certainly can be much shorter than the total key validity period. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA23310 for ietf-open-pgp-bks; Mon, 12 Jul 1999 15:40:32 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA23305 for <ietf-open-pgp@imc.org>; Mon, 12 Jul 1999 15:40:31 -0700 (PDT) Received: from [128.39.29.73] (xing.qualcomm.com [129.46.2.42]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA11385 for <ietf-open-pgp@imc.org>; Mon, 12 Jul 1999 15:41:36 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@127.0.0.1 (Unverified) Message-Id: <v0421010cb3b01d5cb715@[128.39.29.73]> X-Mailer: Eudora [Macintosh version 4.2.1] 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 X-Priority: 2 (High) Date: Tue, 13 Jul 1999 00:39:56 +0200 To: OpenPGP mailing list <ietf-open-pgp@imc.org> From: "John W. Noerenberg" <jwn2@qualcomm.com> Subject: Meeting in Oslo is ON! Content-Type: multipart/alternative; boundary="============_-1280303196==_ma============" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> --============_-1280303196==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Wednesday morning at 9am in Munch. Here's a little more detail for the agenda: OpenPGP Agenda 1. PGP/MIME, PGP/MIME, Wherefore art thou, PGP/MIME? Del Torto and Roessler have a draft, reputedly close to the 2015. They would like to present it, I would like to tie this one up. Has anyone seen Del Torto? 2. Keyserver Synchronization There are two proposals being discussed. Should a new WG be created? 3. Revisions/enhancements/improvements to rfc2440 V5 Signatures MDC Data packet Encryption Mode Normalization Features subpackets Gestalt for non mandatory features Large Block Block ciphers clarifications Suggestions from the floor? 4. Implementor issues Practical experience for what's good & bad about 2440 5. Revision schedule When is successor RFC needed I figure will be out in an hour or less, especially if Jon Callas and I are the only ones who show. I know Jon will be there because I tackled him in the hall today and wouldn't let him go until he promised. Feel free to send me a reassuring word (if nobody shows, I'm gonna have to fork over the cash for the plane fare to my boss... <grin>). best, john noerenberg (in Oslo Jul 10-19, 1999) jwn2@qualcomm.com ---------------------------------------------------------------------- The man that can most truly be accounted brave is he who best knows the meaning of what is sweet in life and what is terrible, and then goes out undeterred to meet what is to come. -- Pericles, "Funeral Oration", 479 B.C. ---------------------------------------------------------------------- --============_-1280303196==_ma============ Content-Type: text/html; charset="us-ascii" <!doctype html public "-//W3C//DTD W3 HTML//EN"> <html><head><style type="text/css"><!-- blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 } --></style><title>Meeting in Oslo is ON!</title></head><body> <div>Wednesday morning at 9am in Munch.</div> <div><br></div> <div>Here's a little more detail for the agenda:</div> <div><br></div> <div><font size="+1" color="#000000"><b>OpenPGP Agenda<br> <br> 1. PGP/MIME, PGP/MIME, Wherefore art thou, PGP/MIME?</b></font></div> <div><font color="#000000"><i><b> Del Torto and Roessler have a draft, reputedly close to the 2015. They would like to present it, I would like to tie this one up. Has anyone seen Del Torto?</b></i></font></div> <div><font color="#000000"><i><b><br></b></i></font></div> <div><font size="+1" color="#000000"><b>2. Keyserver Synchronization</b></font></div> <div><font color="#000000"><i><b>There are two proposals being discussed. Should a new WG be created?</b></i></font></div> <div><font color="#000000"><br></font></div> <div><font size="+1" color="#000000"><b>3. Revisions/enhancements/improvements to rfc2440</b></font></div> <div><font color="#000000"><x-tab> </x-tab>V5 Signatures</font></div> <div><font color="#000000"><x-tab> </x-tab>MDC Data packet</font></div> <div><font color="#000000"><x-tab> </x-tab>Encryption Mode Normalization<br> <x-tab> </x-tab>Features subpackets<i><b><br> </b></i><x-tab> </x-tab><x-tab> </x-tab>Gestalt for non mandatory features</font></div> <div><font color="#000000"><x-tab> </x-tab>Large Block Block ciphers clarifications</font></div> <div><font color="#000000"><i><b><x-tab > </x-tab>Suggestions from the floor?</b></i></font><br> <font color="#000000"><i><b></b></i></font></div> <div><font size="+1" color="#000000"><b>4. Implementor issues<br> </b></font><font color="#000000"><i><b>Practical experience for what's good & bad about 2440</b></i></font><br> <font color="#000000"><i><b></b></i></font></div> <div><font size="+1" color="#000000"><b>5. Revision schedule</b></font></div> <div><font color="#000000"><i><b>When is successor RFC needed</b></i></font></div> <div><font color="#000000"><i><b><br></b></i></font></div> <div>I figure will be out in an hour or less, especially if Jon Callas and I are the only ones who show. I know Jon will be there because I tackled him in the hall today and wouldn't let him go until he promised. Feel free to send me a reassuring word (if nobody shows, I'm gonna have to fork over the cash for the plane fare to my boss... <grin>).</div> <div><br></div> <div>best,</div> <div><br> john noerenberg (in Oslo Jul 10-19, 1999)<br> jwn2@qualcomm.com<br> ----------------------------------------<span ></span>------------------------------<br> The man that can most truly be accounted brave is he who best<br> knows the meaning of what is sweet in life and what is terrible,<br> and then goes out undeterred to meet what is to come.<br> -- Pericles, "Funeral Oration", 479 B.C.<br> ----------------------------------------<span ></span>------------------------------</div> </body> </html> --============_-1280303196==_ma============-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA06367 for ietf-open-pgp-bks; Mon, 12 Jul 1999 01:55:00 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA06362 for <ietf-open-pgp@imc.org>; Mon, 12 Jul 1999 01:54:57 -0700 (PDT) Received: from [0.0.0.0] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Mon, 12 Jul 1999 00:55:58 -0800 X-Sender: jon@127.0.0.1 Message-Id: <v04003a03b3af5d0deb7b@[0.0.0.0]> In-Reply-To: <19990709144402.A41480@public.uni-hamburg.de> References: <v04003a09b3ab260d4be6@[10.5.63.113]>; from Jon Callas on Thu, Jul 08, 1999 at 11:39:48PM -0700 <v04205505b3a874fdb953@[199.106.106.131]> <v04205505b3a874fdb953@[199.106.106.131]> <m112KGg-000QdzC@epsilon> <v04003a09b3ab260d4be6@[10.5.63.113]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 Jul 1999 09:55:04 +0100 To: ietf-open-pgp@imc.org From: Jon Callas <jon@callas.org> Subject: Key expiration Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> At 5:44 AM -0700 7/9/1999, Bodo Moeller said: Me too. I did not detail this in my previous message, but IMO the way to go is to use short validity periods on your encryption keys (so that if you let them expire, no-one will send you mail encrypted to those keys any more; an additional advantage is that you can change the cipher preferences etc. if you switch to newer software versions) and a longer validity period for the signing key. Also your signing key could use a long _key_ validity period, but short _signature_ validity periods for the self-signatures; then the key validity period, if defined, should be used by others who certify that key. A signing key is really invalid only when publishing its secret part cannot break anything (not that I recommend doing so ...). > [...] The self-signature! Not the whole key, unless you don't re-validate. For this, a signature validity period should be used, not a key validity period. We're in violent agreement here. The problem is that "key expiration" in OpenPGP (well, actually in the V4 data structures) is in the self signature. If you look at the V3 key packet, there's a key expiration. In the V4 structure, it is gone. It's in the self-sig. Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA01251 for ietf-open-pgp-bks; Sun, 11 Jul 1999 04:05:08 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA01247 for <ietf-open-pgp@imc.org>; Sun, 11 Jul 1999 04:05:07 -0700 (PDT) Received: from [128.39.29.73] (xing.qualcomm.com [129.46.2.42]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id EAA02152; Sun, 11 Jul 1999 04:06:03 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@127.0.0.1 (Unverified) Message-Id: <v04210100b3ae2a6f698b@[129.46.85.107]> X-Mailer: Eudora [Macintosh version 4.2.1] 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: Sun, 11 Jul 1999 13:05:30 +0200 To: OpenPGP mailing list <ietf-open-pgp@imc.org> From: "John W. Noerenberg" <jwn2@qualcomm.com> Subject: Meeting in Oslo is ON! Cc: "Jeffrey I. Schiller" <jis@mit.edu>, agenda@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Wednesday morning at 9am in Munch. Agenda will follow. See you there! Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20932 for ietf-open-pgp-bks; Sat, 10 Jul 1999 13:11:29 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20928 for <ietf-open-pgp@imc.org>; Sat, 10 Jul 1999 13:11:28 -0700 (PDT) Received: from [129.46.85.64] (annex1-p54.qualcomm.com [129.46.85.64]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id NAA26075; Sat, 10 Jul 1999 13:12:15 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com (Unverified) Message-Id: <v04205509b3ac80fb8d80@[192.168.1.65]> In-Reply-To: <199907081355.JAA18891@tonga.xedia.com> References: <v04003a09b391b1a8a44e@[10.5.63.113]> <v04003a03b390ad882d32@[10.5.63.113]> <v04205504b3a8704d9f84@[199.106.106.131]> <v04003a11b3a9f85913d3@[38.232.7.7]> <199907081355.JAA18891@tonga.xedia.com> X-Mailer: Eudora [Macintosh version 4.2.1] 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: Sat, 10 Jul 1999 06:52:45 +0200 To: Paul Koning <pkoning@xedia.com> From: "John W. Noerenberg" <jwn2@qualcomm.com> Subject: Re: V5 signatures Cc: jon@callas.org, ietf-open-pgp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> At 9:55 AM -0400 7/8/99, Paul Koning wrote: >I'd put it more strongly than that. Any implementation of any >protocol is defective if it crashes when presented with ANY message, >including messages deliberately and maliciously constructed. It's >always allowed to complain, or toss the message, or stuff like that, >but "you sent me an invalid message" will never excuse a crash. Crashing is right out. But misinterpretation and wandering off into some odd corner mumbling to oneself isn't crashing, but equally useless. Protocol changes that provoke massive misbehavior on the part of deployed implemenations aren't a real good idea. If implementors don't squawk, or at least do no worse than shrug indifferently, I'm at ease. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23994 for ietf-open-pgp-bks; Fri, 9 Jul 1999 07:44:43 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23982 for <ietf-open-pgp@imc.org>; Fri, 9 Jul 1999 07:44:30 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id QAA08330 for ietf-open-pgp@imc.org; Fri, 9 Jul 1999 16:45:06 +0200 (MET DST) Received: from (frodo.isil.d.shuttle.de) [172.20.1.4] (mail) by beren.isil.d.shuttle.de with esmtp (Exim 1.92 #1 (Debian)) id 112brW-0003T3-00; Fri, 9 Jul 1999 16:42:50 +0200 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 2.05 #1 (Debian)) id 112bsp-0001Kp-00; Fri, 9 Jul 1999 16:44:11 +0200 Date: Fri, 9 Jul 1999 16:44:11 +0200 From: Werner Koch <wk@isil.d.shuttle.de> To: ietf-open-pgp@imc.org Subject: Expiration dates (was: Rip Van Winkle awakes: meeting in Oslo?) Message-ID: <19990709164411.E5060@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <v04205505b3a874fdb953@[199.106.106.131]> <v04205505b3a874fdb953@[199.106.106.131]> <m112KGg-000QdzC@epsilon> <v04003a09b3ab260d4be6@[10.5.63.113]> <19990709144402.A41480@public.uni-hamburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <19990709144402.A41480@public.uni-hamburg.de>; from Bodo Moeller on Fri, Jul 09, 1999 at 02:44:02PM +0200 X-URL: http://www.openit.de/wks Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Bodo Moeller <in5y094@public.uni-hamburg.de> writes: > The self-signature! Not the whole key, unless you don't re-validate. > For this, a signature validity period should be used, not a key IIRC, I have never seen a direct key signature with an expiration date - so the only available expiration date is the one from the (latest) self-signature on a user ID. I have considered to add the expiration date to the key but there is no strategy defined how to process multiple expiration dates. I think this should be addressed in the next revision of OpenPGP along with some other similar issues (e.g. can a revocation of a self-signature on a user ID been overridden by a newer self-signature). -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21374 for ietf-open-pgp-bks; Fri, 9 Jul 1999 05:43:17 -0700 (PDT) Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21369 for <ietf-open-pgp@imc.org>; Fri, 9 Jul 1999 05:43:12 -0700 (PDT) Received: (from in5y094@localhost) by public.uni-hamburg.de (8.8.8/8.8.8) id OAA74324; Fri, 9 Jul 1999 14:44:03 +0200 Message-ID: <19990709144402.A41480@public.uni-hamburg.de> Date: Fri, 9 Jul 1999 14:44:02 +0200 From: Bodo Moeller <in5y094@public.uni-hamburg.de> To: Jon Callas <jon@callas.org>, Bodo Moeller <Bodo_Moeller@public.uni-hamburg.de>, ietf-open-pgp@imc.org Subject: Re: Rip Van Winkle awakes: meeting in Oslo? References: <v04205505b3a874fdb953@[199.106.106.131]> <v04205505b3a874fdb953@[199.106.106.131]> <m112KGg-000QdzC@epsilon> <v04003a09b3ab260d4be6@[10.5.63.113]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <v04003a09b3ab260d4be6@[10.5.63.113]>; from Jon Callas on Thu, Jul 08, 1999 at 11:39:48PM -0700 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> On Thu, Jul 08, 1999 at 11:39:48PM -0700, Jon Callas wrote: [...] > I think you have a good point, but I also disagree at least a little. > > One of the things that I'd like to see software do operationally is > something I call "rolling validity." I'd like to see keys have a relatively > short life that keeps getting pushed out, by being re-validated. Me too. I did not detail this in my previous message, but IMO the way to go is to use short validity periods on your encryption keys (so that if you let them expire, no-one will send you mail encrypted to those keys any more; an additional advantage is that you can change the cipher preferences etc. if you switch to newer software versions) and a longer validity period for the signing key. Also your signing key could use a long _key_ validity period, but short _signature_ validity periods for the self-signatures; then the key validity period, if defined, should be used by others who certify that key. A signing key is really invalid only when publishing its secret part cannot break anything (not that I recommend doing so ...). > [...] today my OpenPGP software tells me that come August 1, my self-sig > will expire. The self-signature! Not the whole key, unless you don't re-validate. For this, a signature validity period should be used, not a key validity period. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA07987 for ietf-open-pgp-bks; Thu, 8 Jul 1999 23:44:54 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA07981 for <ietf-open-pgp@imc.org>; Thu, 8 Jul 1999 23:44:50 -0700 (PDT) Received: from [10.5.63.113] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Thu, 8 Jul 1999 22:45:34 -0800 X-Sender: jon@127.0.0.1 Message-Id: <v04003a09b3ab260d4be6@[10.5.63.113]> In-Reply-To: <m112KGg-000QdzC@epsilon> References: <v04205505b3a874fdb953@[199.106.106.131]> <v04205505b3a874fdb953@[199.106.106.131]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Jul 1999 23:39:48 -0700 To: Bodo_Moeller@public.uni-hamburg.de (Bodo Moeller), ietf-open-pgp@imc.org From: Jon Callas <jon@callas.org> Subject: Re: Rip Van Winkle awakes: meeting in Oslo? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> At 12:55 PM -0700 7/8/1999, Bodo Moeller said: BTW, was this ever discussed: It should be mentioned (in the Security Considerations section, if not in the specification text) that, when signing a certificate for a signing key that has a key expiration time set in a self-signature, it is unwise not to include a signature expiration time subpacket defining a validity period that extends no longer into the future than the key's validity period. If this rule is not obeyed when certifying keys, then the key validity period is effectively just a key usage period. There's no difference as far as encryption is concerned, but for signing keys the key expiration time sub-packet would be rendered all but meaningless: you could just as well simply stop using the key without declaring so in advance. The big problem is that if attackers learn the secret part of the "expired" signing key, they can easily generate a new self-signature with an adjusted validity period unless the original validity period is duplicated in the key certificates. (This potential flaw does not apply to keys in version 3 public key packets, because they have the validity period defined in the key packet itself, not in a self-signature packet, which means that it is automatically covered by all certificates.) No, this has never been discussed. I think you have a good point, but I also disagree at least a little. One of the things that I'd like to see software do operationally is something I call "rolling validity." I'd like to see keys have a relatively short life that keeps getting pushed out, by being re-validated. As an example, I might have my validity period be three months. Perhaps then, today my OpenPGP software tells me that come August 1, my self-sig will expire. Maybe I should re-validate now. I concur, retype my passphrase, and the new expiration time is November. It sends my updated key to any servers I need it to go to. I think one of the major problems we have is lost keys dangling around forever. If software used something like rolling validity, lost keys would time out, people who don't use their keys much would be noticible. Presently, since the UI doesn't let you unexpire a key, no one makes keys with expiry, except for certain, limited uses (for example, where I work we just put an expiration on a summer intern's key). But today a key with an expiry is the exception. I'd rather see it be the rule. For it to be the rule, there can't be a huge penalty for doing so. Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA26496 for ietf-open-pgp-bks; Thu, 8 Jul 1999 13:02:15 -0700 (PDT) Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26491 for <ietf-open-pgp@imc.org>; Thu, 8 Jul 1999 13:02:02 -0700 (PDT) Received: from max2-038.public.uni-hamburg.de (max2-038.public.uni-hamburg.de [134.100.45.38]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id WAA51034 for <ietf-open-pgp@imc.org>; Thu, 8 Jul 1999 22:02:43 +0200 Received: id <m112KGg-000QdzC@epsilon>; Thu, 8 Jul 1999 21:55:38 +0200 (CEST) Message-Id: <m112KGg-000QdzC@epsilon> Date: Thu, 8 Jul 1999 21:55:38 +0200 (CEST) From: Bodo_Moeller@public.uni-hamburg.de (Bodo Moeller) To: ietf-open-pgp@imc.org Subject: Re: Rip Van Winkle awakes: meeting in Oslo? In-Reply-To: <v04205505b3a874fdb953@[199.106.106.131]> References: <v04205505b3a874fdb953@[199.106.106.131]> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> "John W. Noerenberg" <jwn2@qualcomm.com>: > 3. Numerous revisions/enhancements/improvements to rfc2440 have been proposed > Jon Callas enumerated several items back in April. Some of them have > been discussed on the list recently (notably V5 sigs). Is there > interest in any of the others? BTW, was this ever discussed: 5.2.3. Version 4 Signature Packet Format 5.2.3.5. Key expiration time (4 octet time field) The validity period of the key. This is the number of seconds after the key creation time that the key expires. If this is not present or has a value of zero, the key never expires. This is found only on a self-signature. 5.2.3.9. Signature expiration time (4 octet time field) The validity period of the signature. This is the number of seconds after the signature creation time that the signature expires. If this is not present or has a value of zero, it never expires. It should be mentioned (in the Security Considerations section, if not in the specification text) that, when signing a certificate for a signing key that has a key expiration time set in a self-signature, it is unwise not to include a signature expiration time subpacket defining a validity period that extends no longer into the future than the key's validity period. If this rule is not obeyed when certifying keys, then the key validity period is effectively just a key usage period. There's no difference as far as encryption is concerned, but for signing keys the key expiration time sub-packet would be rendered all but meaningless: you could just as well simply stop using the key without declaring so in advance. The big problem is that if attackers learn the secret part of the "expired" signing key, they can easily generate a new self-signature with an adjusted validity period unless the original validity period is duplicated in the key certificates. (This potential flaw does not apply to keys in version 3 public key packets, because they have the validity period defined in the key packet itself, not in a self-signature packet, which means that it is automatically covered by all certificates.) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25255 for ietf-open-pgp-bks; Thu, 8 Jul 1999 11:54:27 -0700 (PDT) Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25251 for <ietf-open-pgp@imc.org>; Thu, 8 Jul 1999 11:54:25 -0700 (PDT) Received: from max1-140.public.uni-hamburg.de (max1-140.public.uni-hamburg.de [134.100.43.140]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id UAA28464 for <ietf-open-pgp@imc.org>; Thu, 8 Jul 1999 20:55:10 +0200 Received: id <m112JU4-000QdzC@epsilon>; Thu, 8 Jul 1999 21:05:24 +0200 (CEST) Message-Id: <m112JU4-000QdzC@epsilon> Date: Thu, 8 Jul 1999 21:05:24 +0200 (CEST) From: Bodo_Moeller@public.uni-hamburg.de (Bodo Moeller) To: ietf-open-pgp@imc.org Subject: Re: PGP 6.5.1 - word list and SDAs? In-Reply-To: <378334DE.119ADA3E@cyphers.net> References: <19990707111435.B28643@sobolev.rhein.de> <37831FF6.AB95A116@cyphers.net> <19990707122008.B1329@sobolev.rhein.de> <378334DE.119ADA3E@cyphers.net> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Will Price <wprice@cyphers.net>: > The word list is a feature we implemented to provide better biometric > properties for key fingerprint authentication. [...] > Saying that this should have gone through OpenPGP in > the first place is like saying the PGPkeys GUI and whether RSA keys > are silver or gold should go through OpenPGP. How's that? I don't care how the user interface that somebody else uses looks like, but I certainly may want to verify their key fingerprint. > In theory, it's an > interesting concept to write a standard for such things so that > everybody using any implementation knows that RSA keys are silver, > but that's not the role of the IETF. Coloured icons have nothing to do with key fingerprints. Fingerprints are an issue for interoperability; GUI details are not. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA18420 for ietf-open-pgp-bks; Thu, 8 Jul 1999 06:55:22 -0700 (PDT) Received: from wodc7-1.relay.mail.uu.net (wodc7-1.relay.mail.uu.net [199.171.54.114]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA18416 for <ietf-open-pgp@imc.org>; Thu, 8 Jul 1999 06:55:20 -0700 (PDT) Received: from xedia.com by wodc7mr0.ffx.ops.us.uu.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgwzf22835; Thu, 8 Jul 1999 13:56:03 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA07976; Thu, 8 Jul 99 09:54:51 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA18891; Thu, 8 Jul 1999 09:55:59 -0400 Date: Thu, 8 Jul 1999 09:55:59 -0400 Message-Id: <199907081355.JAA18891@tonga.xedia.com> From: Paul Koning <pkoning@xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: jon@callas.org Cc: ietf-open-pgp@imc.org Subject: Re: V5 signatures References: <v04003a09b391b1a8a44e@[10.5.63.113]> <v04003a03b390ad882d32@[10.5.63.113]> <v04205504b3a8704d9f84@[199.106.106.131]> <v04003a11b3a9f85913d3@[38.232.7.7]> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> >>>>> "Jon" == Jon Callas <jon@callas.org> writes: Jon> An implementation is flawed (in my opinion) if it does something Jon> horrid with a future message. If a current implementation finds Jon> a V120 signature today (which is either a data error, or Jon> evidence of time travel), it shouldn't bus error, it should make Jon> some appropriate whimper. I'd put it more strongly than that. Any implementation of any protocol is defective if it crashes when presented with ANY message, including messages deliberately and maliciously constructed. It's always allowed to complain, or toss the message, or stuff like that, but "you sent me an invalid message" will never excuse a crash. paul Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA03490 for ietf-open-pgp-bks; Wed, 7 Jul 1999 23:56:56 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA03484 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 23:56:52 -0700 (PDT) Received: from [38.232.7.7] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 7 Jul 1999 22:57:22 -0800 X-Sender: jon@127.0.0.1 Message-Id: <v04003a11b3a9f85913d3@[38.232.7.7]> In-Reply-To: <v04205504b3a8704d9f84@[199.106.106.131]> References: <v04003a09b391b1a8a44e@[10.5.63.113]> <v04003a03b390ad882d32@[10.5.63.113]> <v04003a09b391b1a8a44e@[10.5.63.113]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 Jul 1999 23:44:39 -0700 To: "John W. Noerenberg" <jwn2@qualcomm.com> From: Jon Callas <jon@callas.org> Subject: Re: V5 signatures Cc: "William H. Geiger III" <whgiii@openpgp.net>, hal@finney.org, wk@isil.d.shuttle.de, ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> At 8:07 PM -0700 7/6/1999, John W. Noerenberg said: Well, you have to identify the signature type, too. However the changes sound minimal. How many implementors are interested in supporting this? What bad thing happens when an implementation meets a v5 packet it doesn't know how to swallow? Will implementations be able to skip over them? An implementation is flawed (in my opinion) if it does something horrid with a future message. If a current implementation finds a V120 signature today (which is either a data error, or evidence of time travel), it shouldn't bus error, it should make some appropriate whimper. It's up to the implementation what they do. Ignoring it is a fine response to my mind. Other people may have other opinions. If they're implementors, they get to do more than pontificate. Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA28164 for ietf-open-pgp-bks; Wed, 7 Jul 1999 15:06:00 -0700 (PDT) Received: from mail10.svr.pol.co.uk (mail10.svr.pol.co.uk [195.92.193.214]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA28159 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 15:05:57 -0700 (PDT) Received: from modem-56.gadolinium.dialup.pol.co.uk ([62.136.31.184] helo=server.cypherspace.org) by mail10.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 111zp7-0007fM-00; Wed, 7 Jul 1999 23:05:49 +0100 Received: (from adam@localhost) by server.cypherspace.org (8.8.3/8.6.12) id VAA11290; Wed, 7 Jul 1999 21:41:05 +0100 Date: Wed, 7 Jul 1999 21:41:05 +0100 Message-Id: <199907072041.VAA11290@server.cypherspace.org> To: wprice@cyphers.net CC: ietf-open-pgp@imc.org From: Adam Back <adam@cypherspace.org> In-reply-to: <378334DE.119ADA3E@cyphers.net> (message from Will Price on Wed, 07 Jul 1999 04:07:05 -0700) Subject: Re: PGP 6.5.1 - word list and SDAs? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Will Price wrote: > Thomas Roessler wrote: > > On 1999-07-07 02:38:43 -0700, Will Price wrote: > > > > > High level biometric authentication methods that a particular > > > vendor (in this case Network Associates) chooses to implement are > > > well beyond the scope of this list. > > > > >From the context, it should have been obvious to you that by > > "fingerprint" I meant "key fingerprint", and not any biometric > > authentication methods your company may or may not choose to > > implement. > > Yes, it was obvious. You're not seeing what I mean by biometric. > The word list is a feature we implemented to provide better biometric > properties for key fingerprint authentication. I expect the reason Will considers a word encoding of a fingerprint has anything to do with `biometrics' is because (I'm guessing) the word list was first designed for PGPfone where there is no web of trust, and the only authentication is that you can recognise the person at the other end of the phone's voice. In that scenario you are using your human ability to recognise the voice to authenticate a key exchange. You could argue that someone reading a PGP fingerprint (hex or encoded as words) over the phone where you recognise the speakers voice counts as a form of biometric authentication. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27646 for ietf-open-pgp-bks; Wed, 7 Jul 1999 14:52:28 -0700 (PDT) Received: from na-ex-bridge2.nai.com (na-ex-bridge2.nai.com [208.228.228.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27642 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 14:52:28 -0700 (PDT) Received: by na-ex-bridge2.nai.com with Internet Mail Service (5.5.2448.0) id <NTSCJ715>; Wed, 7 Jul 1999 14:56:46 -0700 Message-ID: <6BC5E520D4A4D11184A200A0C99D8FBE034FE357@ca-exchange1.nai.com> From: "Salzman, Noah" <Noah_Salzman@NAI.com> To: Jack Repenning <jackr@informix.com>, Thomas Roessler <roessler@guug.de>, ietf-open-pgp@imc.org Subject: RE: PGP 6.5.1 - word list and SDAs? Date: Wed, 7 Jul 1999 14:54:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> To the best of my knowledge, Jack is right. --Noah-- -----Original Message----- From: Jack Repenning [mailto:jackr@informix.com] Sent: Wednesday, July 07, 1999 2:46 PM To: Salzman, Noah Cc: Thomas Roessler; ietf-open-pgp@imc.org Subject: RE: PGP 6.5.1 - word list and SDAs? At 11:53 AM 07/07/1999 , Salzman, Noah wrote: >You can find the list of words -- and a short description by PRZ -- at the >back of the User's Guide that ships with 6.5.1. ... although the Guide has the same bug as the UI: it's not obvious whether the list should be read top-to-bottom or left-to-right. By checking one easy case, I believe both Guide and UI read left-to-right on the top row, then left-to-right on the second row, and so on. Informix Software, Inc. Jack Repenning Config/Release Mgmt jackr@informix.com 4100 Bohannon Drive M/S: 4100/2 Menlo Park, CA 94025 FAX: 650/926-6571 VOICE: 650/926-1044 PAGE: 800/781-6182 PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E PGP/DSS: 955C 44AD 8FCE 77D4 9494 \ : 4AB2 51F1 3EED 3B82 E870 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27588 for ietf-open-pgp-bks; Wed, 7 Jul 1999 14:48:48 -0700 (PDT) Received: from kingcrab.informix.com (dns3.informix.com [192.147.112.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27584 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 14:48:47 -0700 (PDT) Received: from parrot.informix.com (parrot.mp.informix.com [158.58.8.22]) by kingcrab.informix.com (8.8.5/8.7.3) with ESMTP id OAA09693; Wed, 7 Jul 1999 14:49:30 -0700 (PDT) Received: from mp-jackr (repenning.mp.informix.com [158.58.9.204]) by parrot.informix.com (8.8.8+Sun/8.8.8) with ESMTP id OAA08978; Wed, 7 Jul 1999 14:49:28 -0700 (PDT) Message-Id: <4.2.0.56.19990707144417.00a84ae0@parrot> X-Sender: jackr@parrot X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Wed, 07 Jul 1999 14:45:39 -0700 To: "Salzman, Noah" <Noah_Salzman@NAI.com> From: Jack Repenning <jackr@informix.com> Subject: RE: PGP 6.5.1 - word list and SDAs? Cc: Thomas Roessler <roessler@guug.de>, ietf-open-pgp@imc.org In-Reply-To: <6BC5E520D4A4D11184A200A0C99D8FBE034FE31A@ca-exchange1.nai. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> At 11:53 AM 07/07/1999 , Salzman, Noah wrote: >You can find the list of words -- and a short description by PRZ -- at the >back of the User's Guide that ships with 6.5.1. ... although the Guide has the same bug as the UI: it's not obvious whether the list should be read top-to-bottom or left-to-right. By checking one easy case, I believe both Guide and UI read left-to-right on the top row, then left-to-right on the second row, and so on. Informix Software, Inc. Jack Repenning Config/Release Mgmt jackr@informix.com 4100 Bohannon Drive M/S: 4100/2 Menlo Park, CA 94025 FAX: 650/926-6571 VOICE: 650/926-1044 PAGE: 800/781-6182 PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E PGP/DSS: 955C 44AD 8FCE 77D4 9494 \ : 4AB2 51F1 3EED 3B82 E870 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25230 for ietf-open-pgp-bks; Wed, 7 Jul 1999 11:52:14 -0700 (PDT) Received: from na-ex-bridge2.nai.com (na-ex-bridge2.nai.com [208.228.228.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25226 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 11:52:13 -0700 (PDT) Received: by na-ex-bridge2.nai.com with Internet Mail Service (5.5.2448.0) id <NTSCJTL3>; Wed, 7 Jul 1999 11:56:25 -0700 Message-ID: <6BC5E520D4A4D11184A200A0C99D8FBE034FE31A@ca-exchange1.nai.com> From: "Salzman, Noah" <Noah_Salzman@NAI.com> To: Thomas Roessler <roessler@guug.de>, ietf-open-pgp@imc.org Subject: RE: PGP 6.5.1 - word list and SDAs? Date: Wed, 7 Jul 1999 11:53:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> You can find the list of words -- and a short description by PRZ -- at the back of the User's Guide that ships with 6.5.1. --Noah-- -----Original Message----- From: Thomas Roessler [mailto:roessler@guug.de] Sent: Wednesday, July 07, 1999 2:15 AM To: ietf-open-pgp@imc.org Subject: PGP 6.5.1 - word list and SDAs? It would have been nice to have had some specifications on _this_ list _beforehand_: - What do the SDAs look like? Not everyone is using the same platform, so documentation of the data format would have been nice. - What's the word list mapping for fingerprints? I think this should be published at least as an informational RFC, so third-party products can produce compatible "fingerprint sentences". Thanks, tlr ----- Forwarded message from Cody Brownstein <cbrownst@MEDIAONE.NET> ----- Date: Tue, 6 Jul 1999 18:21:39 -0700 From: Cody Brownstein <cbrownst@MEDIAONE.NET> Subject: PGP 6.5.1 has been released To: BUGTRAQ@SECURITYFOCUS.COM <http://web.mit.edu/network/pgp.html> NEW FEATURES IN 6.5.1 PGPnet. PGPnet is a landmark product in the history of PGP. PGPnet secures all TCP/IP communications between itself and any other machine running PGPnet. PGPnet has been successfully tested with Cisco routers(requires Cisco IOS 12.0(4) or later with IPSec TripleDES), Linux FreeS/WAN, and many others. Self-Decrypting Archives. You may now encrypt files or folders into Self-Decrypting Archives (SDA) which can be used by users who do not even have PGP. The archives are completely independent of any application, compressed and protected by PGP's strong cryptography. Integrated PGP Command Line. This version incorporates the popular command line version of PGP for Windows platforms. This product provides you a convenient way to integrate PGP with other Windows applications and automated processes on your desktop system. Please note that this is intended for single user/workstation use. For use on servers, customers are required to purchase the PGP Command Line/Batch Server product. Please contact your local Network Associates Sales representative for more information. Automated Freespace Wiping. PGP's Freespace Wipe feature now allows you to use the Windows Task Scheduler to schedule periodic secure wiping of the freespace on your disk. Hotkeys. The Use Current Window feature has been significantly enhanced by the addition of Hotkeys. By pressing the configured key combination, the Encrypt/Decrypt/Sign functions can be automatically invoked in zero clicks without using PGPtray. Fingerprint Word List. When verifying a PGP public key fingerprint, you can now choose to view the fingerprint as a word list instead of hexadecimal characters. The word list in the fingerprint text box is made up of special authentication words that PGP uses and are carefully selected to be phonetically distinct and easy to understand without phonetic ambiguity. Support for Outlook 2000 and Outlook Express 5.0. This version of PGP adds support for sending and receiving encrypted e-mail in Microsoft Outlook 2000 and Outlook Express 5.0. HTTP Proxy Support. If you are behind a corporate firewall with an HTTP proxy server, PGP now supports accessing HTTP keyservers through the proxy. To use this feature, you must configure the proxy server address in your Internet Explorer preferences. Smart Word Wrapping. The word wrapping in PGP now automatically rewraps paragraphs and even quoted paragraphs resulting in much cleaner signed messages. ----- Cody Brownstein <cbrownst@mediaone.net> ----- PGP Fingerprint: 291B 5051 B97F 8B30 49F8 A068 15CF 26D6 E4DE 5291 ----- End forwarded message ----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23808 for ietf-open-pgp-bks; Wed, 7 Jul 1999 09:50:59 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23803 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 09:50:44 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id SAA00850 for ietf-open-pgp@imc.org; Wed, 7 Jul 1999 18:51:24 +0200 (MET DST) Received: from (frodo.isil.d.shuttle.de) [172.20.1.4] (mail) by beren.isil.d.shuttle.de with esmtp (Exim 1.92 #1 (Debian)) id 111um8-0002Pj-00; Wed, 7 Jul 1999 18:42:24 +0200 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 2.05 #1 (Debian)) id 111un1-0005yj-00; Wed, 7 Jul 1999 18:43:19 +0200 Date: Wed, 7 Jul 1999 18:43:19 +0200 From: Werner Koch <wk@gnupg.org> To: ietf-open-pgp@imc.org Subject: Re: V5 signatures Message-ID: <19990707184319.K12309@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <v04003a03b390ad882d32@[10.5.63.113]> <v04003a09b391b1a8a44e@[10.5.63.113]> <v04205504b3a8704d9f84@[199.106.106.131]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <v04205504b3a8704d9f84@[199.106.106.131]>; from John W. Noerenberg on Wed, Jul 07, 1999 at 12:07:33PM +0900 X-URL: http://www.openit.de/wks Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> "John W. Noerenberg" <jwn2@qualcomm.com> writes: > Well, you have to identify the signature type, too. However the > changes sound minimal. I still believe that putting large amounts of data into a signature packet is not a good design - and therefore I don't think we really need this. What we need more, is an agreement on how to do the MDC packet and to clarify some blocksize>64 issues. > know how to swallow? Will implementations be able to skip over them? Sure, that's why we have version numbers. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23153 for ietf-open-pgp-bks; Wed, 7 Jul 1999 09:08:45 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23148 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 09:08:43 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id MAA23222; Wed, 7 Jul 1999 12:08:32 -0400 Message-Id: <199907071608.MAA23222@domains.invweb.net> From: "William H. Geiger III" <whgiii@openpgp.net> Date: Wed, 07 Jul 1999 11:03:00 -0500 To: "John W. Noerenberg" <jwn2@qualcomm.com> In-Reply-To: <v04205504b3a8704d9f84@[199.106.106.131]> Cc: Jon Callas <jon@callas.org>, hal@finney.org, wk@isil.d.shuttle.de, ietf-open-pgp@imc.org Subject: Re: V5 signatures Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> In <v04205504b3a8704d9f84@[199.106.106.131]>, on 07/07/99 at 12:07 PM, "John W. Noerenberg" <jwn2@qualcomm.com> said: >At 2:11 PM -0700 6/19/99, Jon Callas wrote: >>Bill, the only difference between a V4 sig and a V5 sig is changing the >>length field. The only place that really needs these is standalone >>signatures, (and arguably not even them -- you are after all making that >>very argument). >Well, you have to identify the signature type, too. However the changes >sound minimal. >How many implementors are interested in supporting this? What bad thing >happens when an implementation meets a v5 packet it doesn't know how to >swallow? Will implementations be able to skip over them? I don't know what other developers are doing but IMHO no program should crash because of input data. It is a design failure if they do. Then again in this day and age where program quality takes a back seat to marketing it is an all too common problem. :( -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net 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 5.0 at: http://www.openpgp.net/pgp.html Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii Hi Jeff!! :) --------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22441 for ietf-open-pgp-bks; Wed, 7 Jul 1999 08:40:48 -0700 (PDT) Received: from kingcrab.informix.com (dns3.informix.com [192.147.112.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22437 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 08:40:46 -0700 (PDT) Received: from parrot.informix.com (parrot.informix.com [158.58.8.22]) by kingcrab.informix.com (8.8.5/8.7.3) with ESMTP id IAA22357; Wed, 7 Jul 1999 08:41:28 -0700 (PDT) Received: from mp-jackr (repenning.mp.informix.com [158.58.9.204]) by parrot.informix.com (8.8.8+Sun/8.8.8) with ESMTP id IAA15975; Wed, 7 Jul 1999 08:41:26 -0700 (PDT) Message-Id: <4.2.0.56.19990707082455.00a669a0@parrot> X-Sender: jackr@parrot X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Wed, 07 Jul 1999 08:35:54 -0700 To: Thomas Roessler <roessler@guug.de> From: Jack Repenning <jackr@informix.com> Subject: Re: PGP 6.5.1 - word list and SDAs? Cc: Will Price <wprice@cyphers.net>, ietf-open-pgp@imc.org In-Reply-To: <19990707135605.B8426@sobolev.rhein.de> References: <378334DE.119ADA3E@cyphers.net> <19990707111435.B28643@sobolev.rhein.de> <37831FF6.AB95A116@cyphers.net> <19990707122008.B1329@sobolev.rhein.de> <378334DE.119ADA3E@cyphers.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> At 04:56 AM 07/07/1999 , Thomas Roessler wrote: >Unlike this, the fingerprint (and any redundant exchange format >defined for it) will be exchanged between users. There are many important things in life that none the less don't belong in this particular document. Does the OpenPGP Standard specify that the UI must present fingerprints in hex? I don't think so; perhaps I missed it. Never the less, it's vital that all implementations do so: if mine shows the fingerprint in decimal while yours uses hex, we're unlikely to manage a verification. It's important, but it's not a part of the packet format. Informix Software, Inc. Jack Repenning Config/Release Mgmt jackr@informix.com 4100 Bohannon Drive M/S: 4100/2 Menlo Park, CA 94025 FAX: 650/926-6571 VOICE: 650/926-1044 PAGE: 800/781-6182 PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E PGP/DSS: 955C 44AD 8FCE 77D4 9494 \ : 4AB2 51F1 3EED 3B82 E870 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA21684 for ietf-open-pgp-bks; Wed, 7 Jul 1999 08:18:14 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA21676 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 08:18:09 -0700 (PDT) Received: from [129.46.85.67] (annex1-p57.qualcomm.com [129.46.85.67]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id IAA12874; Wed, 7 Jul 1999 08:18:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com (Unverified) Message-Id: <v04205504b3a8704d9f84@[199.106.106.131]> In-Reply-To: <v04003a09b391b1a8a44e@[10.5.63.113]> References: <v04003a03b390ad882d32@[10.5.63.113]> <v04003a09b391b1a8a44e@[10.5.63.113]> X-Mailer: Eudora [Macintosh version 4.2] 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: Wed, 7 Jul 1999 12:07:33 +0900 To: Jon Callas <jon@callas.org> From: "John W. Noerenberg" <jwn2@qualcomm.com> Subject: Re: V5 signatures Cc: "William H. Geiger III" <whgiii@openpgp.net>, hal@finney.org, wk@isil.d.shuttle.de, ietf-open-pgp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> At 2:11 PM -0700 6/19/99, Jon Callas wrote: >Bill, the only difference between a V4 sig and a V5 sig is changing the >length field. The only place that really needs these is standalone >signatures, (and arguably not even them -- you are after all making that >very argument). Well, you have to identify the signature type, too. However the changes sound minimal. How many implementors are interested in supporting this? What bad thing happens when an implementation meets a v5 packet it doesn't know how to swallow? Will implementations be able to skip over them? john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- The man that can most truly be accounted brave is he who best knows the meaning of what is sweet in life and what is terrible, and then goes out undeterred to meet what is to come. -- Pericles, "Funeral Oration", 479 B.C. ---------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA21662 for ietf-open-pgp-bks; Wed, 7 Jul 1999 08:17:40 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA21658 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 08:17:39 -0700 (PDT) Received: from [129.46.85.67] (annex1-p57.qualcomm.com [129.46.85.67]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id IAA12907 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 08:18:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com (Unverified) Message-Id: <v04205505b3a874fdb953@[199.106.106.131]> X-Mailer: Eudora [Macintosh version 4.2] 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: Wed, 7 Jul 1999 12:14:50 +0900 To: OpenPGP mailing list <ietf-open-pgp@imc.org> From: "John W. Noerenberg" <jwn2@qualcomm.com> Subject: Rip Van Winkle awakes: meeting in Oslo? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Rumor has it I'm waking up in Oslo this weekend. I'll be recounting my dreams in the hotel bar, but in the meantime, a couple of folks have asked if there will be a WG meeting. There are a few things to discuss: 1. PGP/MIME, PGP/MIME, Wherefore art thou, PGP/MIME? Del Torto and Roessler have a draft, reputedly close to the 2015. They would like to present it, I would like to tie this one up. 2. Keyserver Synchronization There are two proposals being discussed. Should a new WG be created? 3. Numerous revisions/enhancements/improvements to rfc2440 have been proposed Jon Callas enumerated several items back in April. Some of them have been discussed on the list recently (notably V5 sigs). Is there interest in any of the others? I'm negotiating with the agenda folks now about whether we can pull off a meeting. I've got my ear to the wire to see if there's a chorus of "Yay!" or "Don't bother". Let me know what you think. best, john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- The man that can most truly be accounted brave is he who best knows the meaning of what is sweet in life and what is terrible, and then goes out undeterred to meet what is to come. -- Pericles, "Funeral Oration", 479 B.C. ---------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA17527 for ietf-open-pgp-bks; Wed, 7 Jul 1999 06:44:07 -0700 (PDT) Received: from chi6-1.relay.mail.uu.net (chi6-1.relay.mail.uu.net [199.171.54.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA17522 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 06:44:06 -0700 (PDT) Received: from xedia.com by chi6sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgwvm09705; Wed, 7 Jul 1999 13:44:41 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA24263; Wed, 7 Jul 99 09:43:32 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA07728; Wed, 7 Jul 1999 09:44:40 -0400 Date: Wed, 7 Jul 1999 09:44:40 -0400 Message-Id: <199907071344.JAA07728@tonga.xedia.com> From: Paul Koning <pkoning@xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: wprice@cyphers.net Cc: ietf-open-pgp@imc.org Subject: Re: PGP 6.5.1 - word list and SDAs? References: <19990707111435.B28643@sobolev.rhein.de> <37831FF6.AB95A116@cyphers.net> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> >>>>> "Will" == Will Price <wprice@cyphers.net> writes: Will> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Will> Thomas Roessler wrote: >> It would have been nice to have had some specifications on _this_ >> list _beforehand_: >> >> - What do the SDAs look like? Not everyone is using the same >> platform, so documentation of the data format would have been >> nice. Will> Self Decrypting Archives use a proprietary format for which Will> there is no reason for us to publish specs beyond the source Will> code we already publish. SDAs decrypt themselves. No other Will> program should attempt to read them, and we will change the Will> format at will frequently. Each implementation of SDA in PGP Will> uses highly platform dependent features. There are not two Will> ends of this wire. SDAs are irrelevant to this list, and have Will> no relation to the OpenPGP format. I assume SDAs decrypt themselves only if the recipient is using the same CPU type and OS as the sender. Since PGP is in other ways a portable application, I don't think your argument holds water. What if someone sends me an SDA and I want to decrypt it, but I can't just run it because he's using some random OS I don't use? Or I'm using a Sparc? paul Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA17361 for ietf-open-pgp-bks; Wed, 7 Jul 1999 06:36:01 -0700 (PDT) Received: from postfix.rhein.de (aiur.rhein.de [193.175.27.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA17350 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 06:35:52 -0700 (PDT) Received: by postfix.rhein.de (Postfix, from userid 5) id 65B06129D1; Wed, 7 Jul 1999 15:36:31 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id CDA2FF204; Wed, 7 Jul 1999 13:56:05 +0200 (MEST) Date: Wed, 7 Jul 1999 13:56:05 +0200 From: Thomas Roessler <roessler@guug.de> To: Will Price <wprice@cyphers.net> Cc: ietf-open-pgp@imc.org Subject: Re: PGP 6.5.1 - word list and SDAs? Message-ID: <19990707135605.B8426@sobolev.rhein.de> Mail-Followup-To: Will Price <wprice@cyphers.net>, ietf-open-pgp@imc.org References: <19990707111435.B28643@sobolev.rhein.de> <37831FF6.AB95A116@cyphers.net> <19990707122008.B1329@sobolev.rhein.de> <378334DE.119ADA3E@cyphers.net> Mime-Version: 1.0 User-Agent: Mutt/0.96.3i In-Reply-To: <378334DE.119ADA3E@cyphers.net> Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> On 1999-07-07 04:07:05 -0700, Will Price wrote: > However, the feature is a biometric authentication method that has > no relation to the OpenPGP data formats. Sorry, I don't see how an easily pronounceable and audible representation of a key fingerprint has anything to do with what's usually called biometric authentication. Or are you planning to couple PGP with voice recognition and automatic finger print checking? > Saying that this should have gone through OpenPGP in the first > place is like saying the PGPkeys GUI and whether RSA keys are > silver or gold should go through OpenPGP. You're missing the point here. Your user interface is exclusively used to communicate between the software and the user. It is _not_ used in the first place to exchange data between different users. Unlike this, the fingerprint (and any redundant exchange format defined for it) will be exchanged between users. I'm looking forward for the first business card which has the "pronouncable" finger print on its back. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA14094 for ietf-open-pgp-bks; Wed, 7 Jul 1999 04:06:38 -0700 (PDT) Received: from enigma.cyphers.net (enigma.cyphers.net [205.178.102.88]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA14090 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 04:06:37 -0700 (PDT) Received: from cyphers.net (blowfish.cyphers.net [205.178.102.84]) by enigma.cyphers.net (8.9.3/8.8.7) with ESMTP id DAA07059 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 03:07:48 -0700 Message-ID: <378334DE.119ADA3E@cyphers.net> Date: Wed, 07 Jul 1999 04:07:05 -0700 From: Will Price <wprice@cyphers.net> X-Mailer: Mozilla 4.61 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-open-pgp@imc.org Subject: Re: PGP 6.5.1 - word list and SDAs? References: <19990707111435.B28643@sobolev.rhein.de> <37831FF6.AB95A116@cyphers.net> <19990707122008.B1329@sobolev.rhein.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Roessler wrote: > On 1999-07-07 02:38:43 -0700, Will Price wrote: > > > High level biometric authentication methods that a particular > > vendor (in this case Network Associates) chooses to implement are > > well beyond the scope of this list. > > >From the context, it should have been obvious to you that by > "fingerprint" I meant "key fingerprint", and not any biometric > authentication methods your company may or may not choose to > implement. Yes, it was obvious. You're not seeing what I mean by biometric. The word list is a feature we implemented to provide better biometric properties for key fingerprint authentication. > > Technical documentation and mappings for the word lists are > > published in the docs for PGP where they belong. Not in this > > group. > > Sorry, Will, this word mapping _is_ an interchange format for > OpenPGP key properties, so it _does_ belong on this list and into > an (at least informational) Internet RFC. After all, there is a > reason behind having a well-defined key fingerprint displayed to > and exchanged by users, isn't it? I could see a case for documenting the word list we developed into an informational RFC with no relation to this working group. I'm sure we'd be happy to see that happen. However, the feature is a biometric authentication method that has no relation to the OpenPGP data formats. Saying that this should have gone through OpenPGP in the first place is like saying the PGPkeys GUI and whether RSA keys are silver or gold should go through OpenPGP. In theory, it's an interesting concept to write a standard for such things so that everybody using any implementation knows that RSA keys are silver, but that's not the role of the IETF. We still display display the hex fingerprint format. Please feel free to write an informational RFC using the list provided in our documentation. > Concerning the SDAs, having a platform-independent marker string > which indicates where the ciphertext begins shouldn't be such a > great pain, and it would enable independent implementations running > on other platforms than the one intended by the SDA's sender to > extract the ciphertext. (I'm assuming that you don't use a > proprietary format for _all_ of the SDA.) The SDA format will change and is very fluid even now. SDAs are not intended to be sent from one user to another like a PGP message. In many cases, that would violate export controls and introduces other concerns like viruses and trojan horses, and can't be signed. SDAs are a specific customer request we received many times for things like placing conventionally encrypted items in a CD-ROM package. They don't use any public keys, and are not an interchange format. Any other OpenPGP implementation can feel free to implement their own SDAs using their own format. Encouraging standardization of such a format implies that the format is a wise way to exchange encrypted data over the wire when that is clearly not the case. OpenPGP is the solution for exchanging encrypted data on the wire. - -- Will Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1 iQA/AwUBN4M0d6y7FkvPc+xMEQI1JwCfX80qkakGMXiG6vCLuasvHlOv3LUAn3IT PyiWpIXY27Brn7TuTnQnuWo4 =HLuo -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA12466 for ietf-open-pgp-bks; Wed, 7 Jul 1999 03:24:18 -0700 (PDT) Received: from postfix.rhein.de (aiur.rhein.de [193.175.27.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA12410 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 03:24:01 -0700 (PDT) Received: by postfix.rhein.de (Postfix, from userid 5) id 7901112990; Wed, 7 Jul 1999 12:24:38 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id AC6CEF204; Wed, 7 Jul 1999 12:20:08 +0200 (MEST) Date: Wed, 7 Jul 1999 12:20:08 +0200 From: Thomas Roessler <roessler@guug.de> To: ietf-open-pgp@imc.org Subject: Re: PGP 6.5.1 - word list and SDAs? Message-ID: <19990707122008.B1329@sobolev.rhein.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <19990707111435.B28643@sobolev.rhein.de> <37831FF6.AB95A116@cyphers.net> Mime-Version: 1.0 User-Agent: Mutt/0.96.3i In-Reply-To: <37831FF6.AB95A116@cyphers.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA12463 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> On 1999-07-07 02:38:43 -0700, Will Price wrote: > High level biometric authentication methods that a particular > vendor (in this case Network Associates) chooses to implement are > well beyond the scope of this list. >From the context, it should have been obvious to you that by "fingerprint" I meant "key fingerprint", and not any biometric authentication methods your company may or may not choose to implement. > Technical documentation and mappings for the word lists are > published in the docs for PGP where they belong. Not in this > group. Sorry, Will, this word mapping _is_ an interchange format for OpenPGP key properties, so it _does_ belong on this list and into an (at least informational) Internet RFC. After all, there is a reason behind having a well-defined key fingerprint displayed to and exchanged by users, isn't it? Concerning the SDAs, having a platform-independent marker string which indicates where the ciphertext begins shouldn't be such a great pain, and it would enable independent implementations running on other platforms than the one intended by the SDA's sender to extract the ciphertext. (I'm assuming that you don't use a proprietary format for _all_ of the SDA.) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA12366 for ietf-open-pgp-bks; Wed, 7 Jul 1999 03:20:49 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA12360 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 03:20:43 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id MAA23237 for ietf-open-pgp@imc.org; Wed, 7 Jul 1999 12:21:20 +0200 (MET DST) Received: from (frodo.isil.d.shuttle.de) [172.20.1.4] (mail) by beren.isil.d.shuttle.de with esmtp (Exim 1.92 #1 (Debian)) id 111obh-00029e-00; Wed, 7 Jul 1999 12:07:13 +0200 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 2.05 #1 (Debian)) id 111ocX-0003Cn-00; Wed, 7 Jul 1999 12:08:05 +0200 Date: Wed, 7 Jul 1999 12:08:05 +0200 From: Werner Koch <wk@isil.d.shuttle.de> To: ietf-open-pgp@imc.org Subject: Re: PGP 6.5.1 - word list and SDAs? Message-ID: <19990707120804.B12309@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <19990707111435.B28643@sobolev.rhein.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <19990707111435.B28643@sobolev.rhein.de>; from Thomas Roessler on Wed, Jul 07, 1999 at 11:14:35AM +0200 X-URL: http://www.openit.de/wks Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> Thomas Roessler <roessler@guug.de> writes: > - What do the SDAs look like? Not everyone is using the same > platform, so documentation of the data format would have been nice. and how is this related to ITAR? Sending a SDA from the U.S. to Europe seems to be like exporting strong crypto. just wondering.. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA09805 for ietf-open-pgp-bks; Wed, 7 Jul 1999 02:37:31 -0700 (PDT) Received: from enigma.cyphers.net (enigma.cyphers.net [205.178.102.88]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA09801 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 02:37:30 -0700 (PDT) Received: from cyphers.net (blowfish.cyphers.net [205.178.102.84]) by enigma.cyphers.net (8.9.3/8.8.7) with ESMTP id BAA06878 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 01:38:41 -0700 Message-ID: <37831FF6.AB95A116@cyphers.net> Date: Wed, 07 Jul 1999 02:38:43 -0700 From: Will Price <wprice@cyphers.net> X-Mailer: Mozilla 4.61 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-open-pgp@imc.org Subject: Re: PGP 6.5.1 - word list and SDAs? References: <19990707111435.B28643@sobolev.rhein.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Roessler wrote: > > It would have been nice to have had some specifications on _this_ > list _beforehand_: > > - What do the SDAs look like? Not everyone is using the same > platform, so documentation of the data format would have been > nice. Self Decrypting Archives use a proprietary format for which there is no reason for us to publish specs beyond the source code we already publish. SDAs decrypt themselves. No other program should attempt to read them, and we will change the format at will frequently. Each implementation of SDA in PGP uses highly platform dependent features. There are not two ends of this wire. SDAs are irrelevant to this list, and have no relation to the OpenPGP format. > - What's the word list mapping for fingerprints? I think this > should be published at least as an informational RFC, so > third-party products can produce compatible "fingerprint > sentences". High level biometric authentication methods that a particular vendor (in this case Network Associates) chooses to implement are well beyond the scope of this list. These issues have no effect whatsoever on the data format used by OpenPGP. Technical documentation and mappings for the word lists are published in the docs for PGP where they belong. Not in this group. - -- Will Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1 iQA/AwUBN4Mfvqy7FkvPc+xMEQJYJwCdHQgiB3IU5YPaaoxDuZNZdlqNuiUAnixf g7RKxddlDmmxUaaVnR2xMJcC =STgS -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA09344 for ietf-open-pgp-bks; Wed, 7 Jul 1999 02:15:36 -0700 (PDT) Received: from postfix.rhein.de (aiur.rhein.de [193.175.27.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA09339 for <ietf-open-pgp@imc.org>; Wed, 7 Jul 1999 02:15:03 -0700 (PDT) Received: by postfix.rhein.de (Postfix, from userid 5) id 358F112955; Wed, 7 Jul 1999 11:15:15 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id E742DF204; Wed, 7 Jul 1999 11:14:35 +0200 (MEST) Date: Wed, 7 Jul 1999 11:14:35 +0200 From: Thomas Roessler <roessler@guug.de> To: ietf-open-pgp@imc.org Subject: PGP 6.5.1 - word list and SDAs? Message-ID: <19990707111435.B28643@sobolev.rhein.de> Mail-Followup-To: ietf-open-pgp@imc.org Mime-Version: 1.0 User-Agent: Mutt/0.96.3i Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id CAA09341 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> It would have been nice to have had some specifications on _this_ list _beforehand_: - What do the SDAs look like? Not everyone is using the same platform, so documentation of the data format would have been nice. - What's the word list mapping for fingerprints? I think this should be published at least as an informational RFC, so third-party products can produce compatible "fingerprint sentences". Thanks, tlr ----- Forwarded message from Cody Brownstein <cbrownst@MEDIAONE.NET> ----- Date: Tue, 6 Jul 1999 18:21:39 -0700 From: Cody Brownstein <cbrownst@MEDIAONE.NET> Subject: PGP 6.5.1 has been released To: BUGTRAQ@SECURITYFOCUS.COM <http://web.mit.edu/network/pgp.html> NEW FEATURES IN 6.5.1 PGPnet. PGPnet is a landmark product in the history of PGP. PGPnet secures all TCP/IP communications between itself and any other machine running PGPnet. PGPnet has been successfully tested with Cisco routers(requires Cisco IOS 12.0(4) or later with IPSec TripleDES), Linux FreeS/WAN, and many others. Self-Decrypting Archives. You may now encrypt files or folders into Self-Decrypting Archives (SDA) which can be used by users who do not even have PGP. The archives are completely independent of any application, compressed and protected by PGP's strong cryptography. Integrated PGP Command Line. This version incorporates the popular command line version of PGP for Windows platforms. This product provides you a convenient way to integrate PGP with other Windows applications and automated processes on your desktop system. Please note that this is intended for single user/workstation use. For use on servers, customers are required to purchase the PGP Command Line/Batch Server product. Please contact your local Network Associates Sales representative for more information. Automated Freespace Wiping. PGP's Freespace Wipe feature now allows you to use the Windows Task Scheduler to schedule periodic secure wiping of the freespace on your disk. Hotkeys. The Use Current Window feature has been significantly enhanced by the addition of Hotkeys. By pressing the configured key combination, the Encrypt/Decrypt/Sign functions can be automatically invoked in zero clicks without using PGPtray. Fingerprint Word List. When verifying a PGP public key fingerprint, you can now choose to view the fingerprint as a word list instead of hexadecimal characters. The word list in the fingerprint text box is made up of special authentication words that PGP uses and are carefully selected to be phonetically distinct and easy to understand without phonetic ambiguity. Support for Outlook 2000 and Outlook Express 5.0. This version of PGP adds support for sending and receiving encrypted e-mail in Microsoft Outlook 2000 and Outlook Express 5.0. HTTP Proxy Support. If you are behind a corporate firewall with an HTTP proxy server, PGP now supports accessing HTTP keyservers through the proxy. To use this feature, you must configure the proxy server address in your Internet Explorer preferences. Smart Word Wrapping. The word wrapping in PGP now automatically rewraps paragraphs and even quoted paragraphs resulting in much cleaner signed messages. ----- Cody Brownstein <cbrownst@mediaone.net> ----- PGP Fingerprint: 291B 5051 B97F 8B30 49F8 A068 15CF 26D6 E4DE 5291 ----- End forwarded message ----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA18430 for ietf-open-pgp-bks; Fri, 2 Jul 1999 04:10:53 -0700 (PDT) Received: from dns.h.rubin.ch (ares.rubin.ch [212.55.211.122]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA18426 for <ietf-open-pgp@imc.org>; Fri, 2 Jul 1999 04:10:49 -0700 (PDT) Received: from localhost (listen@localhost) by dns.h.rubin.ch (8.9.1/8.9.1/rubin.ch_main $Revision: 1.4 $) with ESMTP id NAA14236; Fri, 2 Jul 1999 13:14:04 +0200 Date: Fri, 2 Jul 1999 13:13:44 +0200 (CEST) From: Patrick Feisthammel <listen@rubin.ch> X-Sender: listen@dns.h.rubin.ch Reply-To: Patrick Feisthammel <pafei@rubin.ch> To: Marcel Waldvogel <mwa@tik.ee.ethz.ch> cc: "William H. Geiger III" <whgiii@openpgp.net>, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol In-Reply-To: <19990702110209.S843@tik.ee.ethz.ch> Message-ID: <Pine.LNX.4.05.9907021253470.1139-100000@dns.h.rubin.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> -----BEGIN PGP SIGNED MESSAGE----- Hi! On Fri, 2 Jul 1999, Marcel Waldvogel wrote: > Both strategies, either keeping the first (revocation) signature or > updating them, is open to DoS. I would prefer the keyservers to keep > (and return) all duplicate (revocation) signatures, but only display > one of them. Then the user's OpenPGP implementation should deal with > it. Duplicate signatures shouldn't break anything, but I would like > to know whether anyone assumes that duplicate revocations might break > something? I do not think they break something. OpenPGP implementation should handle multiple signatures with similar meaning. If there are implementations which have different behaviour according to the additional information of the signature, they can have problems. Such additional informations are the creation time of the signature (an implementation could treat signatures valid if they occured befor the revocation of the key) or the reason for the revocation (if the reason is a changed userID the OpenPGP implementation could take signatures for valid, but not if the reason is a compromised key). IMHO the keyservers should store all key information and not try to guess what part of this information an application needs to work. 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) what ist the web of trust? see http://www.rubin.ch/pgp/weboftrust.en.html Das Vertrauensnetz von PGP: http://www.rubin.ch/pgp/weboftrust.de.html -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQESAwUBN3ye7ZVgYabdk0E5AQFM5AfiA+RtuAFoxpoDU3zPaFBbPcgdKKZH8fYH op3dUWOsVBqXXhCfTYHbvWEr+Z9kZnIzoDlikheVmfjdGmPDi6Q5YuHr/TARdGKH 3v7wK/5kMo1WeiP89Ct6yllP5uVfiuNUnL+qM5k+5pIP5GB4CalscpeCkzAWx6pO IILQVEmsYDIpk+pOUn4nV0S/pH1gi6Qce884dnWxqNnJSB7iLKKeu0Gst+GHrwXN 2N8VhYe347vFO4opv86gRY/kCYA9YuyWhVCSb3E6xtknhCl3eL+n2hjyxJVDx3Wq 8XkvNkCHu/ENiMuxfoRa+F3M5pEKmMJnD6pdfYgFb5uaXiuZRQ== =WRQf -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA15464 for ietf-open-pgp-bks; Fri, 2 Jul 1999 01:57:51 -0700 (PDT) Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA15460 for <ietf-open-pgp@imc.org>; Fri, 2 Jul 1999 01:57:48 -0700 (PDT) Received: from komsys-pc-mw.ethz.ch (mwa@komsys-pc-mw [129.132.66.24]) by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id LAA01931; Fri, 2 Jul 1999 11:01:29 +0200 (MET DST) Received: (from mwa@localhost) by komsys-pc-mw.ethz.ch (8.9.3/8.8.8) id LAA12072; Fri, 2 Jul 1999 11:02:09 +0200 Date: Fri, 2 Jul 1999 11:02:09 +0200 From: Marcel Waldvogel <mwa@tik.ee.ethz.ch> To: "William H. Geiger III" <whgiii@openpgp.net> Cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Message-ID: <19990702110209.S843@tik.ee.ethz.ch> References: <199906302254.AAA12836@tik2.ethz.ch> <199907011734.NAA22352@domains.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907011734.NAA22352@domains.invweb.net>; from William H. Geiger III on Thu, Jul 01, 1999 at 09:27:28AM -0500 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> On Thu, Jul 01, 1999 at 09:27:28AM -0500, "William H. Geiger III" <whgiii@openpgp.net> wrote: > >Unless all keyservers follow exactly the same policies and these policies > >do not depend on the order in which the PGP packets are received, the > >number of unresolved or unresolvable differences will increase. And I am > >not really sure which policy is the "right" one. > > I was not aware that this was going on but it is something that, IMHO, > *must* be addressed. This issue not only affects the key servers but also > the users keyrings. I don't like the idea of the servers making these > types of determinations if they are not doing any verification of the > signatures. It opens up a DOS attack on a key by replacing the self > signature with an invalid signature of a newer date. To be honest I don't > like the idea of the public servers removing anything from an existing > key. It opens up problems that the servers are not in a position to > address. Both strategies, either keeping the first (revocation) signature or updating them, is open to DoS. I would prefer the keyservers to keep (and return) all duplicate (revocation) signatures, but only display one of them. Then the user's OpenPGP implementation should deal with it. Duplicate signatures shouldn't break anything, but I would like to know whether anyone assumes that duplicate revocations might break something? -Marcel Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA04359 for ietf-open-pgp-bks; Thu, 1 Jul 1999 10:30:45 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA04355 for <ietf-open-pgp@imc.org>; Thu, 1 Jul 1999 10:30:44 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id NAA22352; Thu, 1 Jul 1999 13:34:09 -0400 Message-Id: <199907011734.NAA22352@domains.invweb.net> From: "William H. Geiger III" <whgiii@openpgp.net> Date: Thu, 01 Jul 1999 09:27:28 -0500 To: Marcel Waldvogel <mwa@tik.ee.ethz.ch> In-Reply-To: <199906302254.AAA12836@tik2.ethz.ch> Cc: mwa@tik.ee.ethz.ch, Teun.Nijssen@kub.nl, pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> In <199906302254.AAA12836@tik2.ethz.ch>, on 07/01/99 at 12:54 AM, Marcel Waldvogel <mwa@tik.ee.ethz.ch> said: >William, >this was said thinking about duplicate signatures or revocation >certificates or other stuff: >- Many key owners seem to revoke their keys more than once, so many > keys on different servers have different revocation certificates. > (Importing Peter Wan's keyring into my database gives some hundred of > these). >- Many users sign the same UserID more than once. The current pksd > prunes them to all but one. Currently, pksd does this by taking the one > with the newest time stamp. Other keyservers may have a different >policy. - If keyservers are put into place which really check the >validity of the > revocations/signatures before either adding them or allowing them to > replace other revocations or signatures, there may be even more >differences. >Unless all keyservers follow exactly the same policies and these policies >do not depend on the order in which the PGP packets are received, the >number of unresolved or unresolvable differences will increase. And I am >not really sure which policy is the "right" one. I was not aware that this was going on but it is something that, IMHO, *must* be addressed. This issue not only affects the key servers but also the users keyrings. I don't like the idea of the servers making these types of determinations if they are not doing any verification of the signatures. It opens up a DOS attack on a key by replacing the self signature with an invalid signature of a newer date. To be honest I don't like the idea of the public servers removing anything from an existing key. It opens up problems that the servers are not in a position to address. -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net 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 5.0 at: http://www.openpgp.net/pgp.html Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii Hi Jeff!! :) --------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA25801 for ietf-open-pgp-bks; Thu, 1 Jul 1999 02:43:15 -0700 (PDT) Received: from postfix.rhein.de (aiur.rhein.de [193.175.27.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA25797 for <ietf-open-pgp@imc.org>; Thu, 1 Jul 1999 02:43:12 -0700 (PDT) Received: by postfix.rhein.de (Postfix, from userid 5) id B9346128A1; Thu, 1 Jul 1999 11:46:28 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id C37A3F0F6; Thu, 1 Jul 1999 11:32:28 +0200 (MEST) Date: Thu, 1 Jul 1999 11:32:28 +0200 From: Thomas Roessler <roessler@guug.de> To: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Message-ID: <19990701113228.M3079@sobolev.rhein.de> References: <19990624153938.C4137@tik.ee.ethz.ch> <199906301536.LAA28200@domains.invweb.net> Mime-Version: 1.0 User-Agent: Mutt/0.96.3i In-Reply-To: <199906301536.LAA28200@domains.invweb.net> Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/> List-Unsubscribe: <mailto:ietf-open-pgp-request@imc.org?body=unsubscribe> On 1999-06-30 09:59:30 -0500, William H. Geiger III wrote: > There is no reason why a server could not generate a complete hash > table once a month, and then produce a "changes" hash table on a > daily or weekly basis that only contained the new/updated keys > since the last complete hash table was created. This method relies on servers keeping state and thus bears the risk of getting servers out of synch under error conditions. I'd suggest you use something remotely inspired by Andrew Tridgell's rsync algorithm, coupled with a binary search for differences over the key space. (Note: I followed the portion of this thread which went to ietf-open-pgp, so I may have missed some discussion on pgp-keyserver-folk.) Let's assume we have some kind of unique serial number for the key (finger print, etc.), and a method to generate a unique hash for a given key block (that's the packet sorting issue). Let's assume we have sorted the keys by this serial number. We first calculate a key block hash for each key. We then hash together these hashes for each set of keys with the same least-significant byte. (Let's call these hashes h_{1,k}, k being (id >> 8). Note that there will be many k's for which the set over which we have calculated the hash is empty; we don't store, calculate or transmit these sets and hashes at all, saving considerable memory and bandwidth.) We now hash together all h_{1,k}'s where k has the same least-significant byte, yielding h_{2,l}, l being (k >> 8). We repeat this process several times, getting a hierarchy of hashes. Now, the key server initiating the update ("client") transfers the hashes of a certain level to another key server ("server"). This level has to be computed on the base of the rate of changes to which the key servers are subject, and on the number of keys on a server - you don't want to transfer these hashes when there is a high probability that _all_ of them will be different on the two servers; you also don't want to transfer them when most of them are equal. Now, the target server compares his set of hashes and the other server's set of hashes. We can have four situations: - Client transferred a hash which wasn't calculated on server. This means that client has keys in a block which aren't present on server. Server will request all keys matching this block. - Client did not transfer a hash for a block for which server has one. Server will now initiate a transfer of all keys in this block to client. - Client and server have different hashes. In this case, server has two choices: -> Request all keys in this block. This may be an option if server has only few keys in this block (assuming, according to the rate of change, that client hasn't many more keys, either), or if the block itself is small enough. This is another point where you can optimize the protocol by modifying parameters. -> Go down one hash level and repeat the process for this block. - Client and server have identical hashes. Fine.
- typo in rfc2440: secret key packet format Sven Wohlgemuth
- Re: typo in rfc2440: secret key packet format hal
- Re: typo in rfc2440: secret key packet format Sven Wohlgemuth
- Re: typo in rfc2440: secret key packet format hal
- Re: typo in rfc2440: secret key packet format Sven Wohlgemuth