Subject: typo in rfc2440: secret key packet format

From: Sven Wohlgemuth <[email-masked]>
Date: Wed, 28 Jul 1999 11:35:31 +0200 (MET DST)

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

---

From: [email-masked]
Date: Fri, 30 Jul 1999 09:49:52 -0700

Sven Wohlgemuth, <[email-masked]>, 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.

> 								    ===
> 	  =============================================================
> 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

From: [email-masked]
Date: Fri, 30 Jul 1999 09:49:52 -0700
To: [email-masked], [email-masked]
Subject: Re: typo in rfc2440: secret key packet format
Cc: [email-masked]
Sender: [email-masked]

Sven Wohlgemuth, <[email-masked]>, 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.

> 								    ===
> 	  =============================================================
> 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

Date: Fri, 30 Jul 1999 14:44:02 +0200 (MET DST)
To: [email-masked]
From: Sven Wohlgemuth <[email-masked]>
Subject: Re: typo in rfc2440: secret key packet format
Cc: [email-masked]
Sender: [email-masked]

Hello,

thank you for your mail.
But I have another question.

At 8:31 Uhr -0700 28.07.1999, [email-masked] wrote:
>Sven Wohlgemuth, <[email-masked]>, writes:
>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?

>>        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

From: [email-masked]
Date: Wed, 28 Jul 1999 08:31:10 -0700
To: [email-masked], [email-masked]
Subject: Re: typo in rfc2440: secret key packet format
Sender: [email-masked]

>      - [Optional] If string-to-key usage octet was 255, an one-octet

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

Date: Wed, 28 Jul 1999 11:35:31 +0200 (MET DST)
From: Sven Wohlgemuth <[email-masked]>
To: [email-masked]
Subject: typo in rfc2440: secret key packet format 
Sender: [email-masked]

Hello,

   The packet contains:

Regards,
Sven Wohlgemuth

From: [email-masked]
Date: Tue, 27 Jul 1999 12:12:13 -0700
To: [email-masked]
Subject: newsgroups - privacy-HELP!!!!!!!
Sender: [email-masked]

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.  

Date: Tue, 27 Jul 1999 08:44:51 -0700
To: Tony Mione <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: Oslo minutes?
Cc: Dave Del Torto <[email-masked]>, Werner Koch <[email-masked]>, [email-masked]
Sender: [email-masked]

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
[email-masked]
   ----------------------------------------------------------------------
   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.
   ----------------------------------------------------------------------

Date: Tue, 27 Jul 1999 08:44:00 -0700
To: Werner Koch <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: Oslo minutes?
Cc: [email-masked]
Sender: [email-masked]

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 [email-masked], but neglected to 
send them to the list....<sigh>

I've just posted them now.

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   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.
   ----------------------------------------------------------------------

Date: Tue, 27 Jul 1999 08:42:59 -0700
To: OpenPGP mailing list <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: OpenPGP minutes
Sender: [email-masked]

--============_-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:[email-masked]?body=subscribe>
     List-Unsubscribe: <mailto:[email-masked]?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
[email-masked]
   ----------------------------------------------------------------------
   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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</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>
&nbsp; Agenda Bashing<br>
&nbsp; Key Server Synchronization protocols<br>
&nbsp; RFC2440 Revisions<br>
&nbsp; Advance to Draft, Collect $200<br>
&nbsp; RFC2015 Revisions<br>
&nbsp; Summary<br>
<br>
<br>
Agenda Bashing<br>
<br>
Key Server Synchronization protocols<br>
<br>
&nbsp; 2 Proposals<br>
&nbsp;&nbsp;&nbsp; Bill Geiger - Hash table exchange</div>
<div>&nbsp;&nbsp;&nbsp; Marcel Waldvogel - Push-pull flooding</div>
<div>&nbsp; Marcel Waldvogel thesis:<br>
&nbsp; &lt;http://www.tik.ee.ethz.ch/tik/education<span
></span>/sadas/SASS1998-33/thesis.ps.gz&gt;<br>
&nbsp; Bill Geiger: proposal introduction published in<br>
&nbsp; &lt;http://www.imc.org/ietf-open-pgp/mail-a<span
></span>rchive/&gt;</div>
<div>&nbsp; in a messaged dated: Fri, 18 Jun 1999 09:43:36 -0500<br>
<br>
&nbsp; JN: Key Server sync protocols are important. However, they are
not<br>
&nbsp; in our charter. We need to decide whether to change the
charter or<br>
&nbsp; create a new WG.<br>
&nbsp;<br>
&nbsp; JN recommended WG report to SAAG that a new working group
should be explored</div>
<div>&nbsp; for Key Server Synchronization protocols.&nbsp; After
some discussion, there were no<br>
&nbsp; objections to this recommendation.<br>
<br>
RFC2440 Revisions<br>
<br>
&nbsp; JC: Need to decide what should be done to 2440 to get it ready
for draft.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Discussed some of the below.<br>
<br>
&nbsp; V5 Signatures<br>
</div>
<div>&nbsp;&nbsp;&nbsp; Need to have larger signatures to accommodate
the equivalent of<br>
&nbsp;&nbsp;&nbsp; certificates. Possible solution is to add up a 4
byte length. Only<br>
&nbsp;&nbsp;&nbsp; reason to hold off is to think about if anything
else needs to<br>
&nbsp;&nbsp;&nbsp; change other than the length field format.<br>
<br>
&nbsp; [ Side conversation about closing off the group and leaving
the<br>
&nbsp; fixes to a future group. JN: OpenPGP will exist until 2440
goes to<br>
&nbsp; Draft so we can go and fix this. In the interest of going to
draft,<br>
&nbsp; the changes should be short at this time. MDC is clearly the
most<br>
&nbsp; important.]<br>
<br>
&nbsp; MDC Data packet - Need a way to detect packet damage.
Currently, a<br>
&nbsp;&nbsp;&nbsp; packet may be maliciously damaged by re-arranging
blocks. Easiest</div>
<div>&nbsp;&nbsp;&nbsp; way to fix this is to append a hash,
preferably sha-1.<br>
<br>
&nbsp;&nbsp;&nbsp; Encryption Mode Normalization<br>
</div>
<div>&nbsp; Features subpackets - This will provide a way for
different PGPs to<br>
&nbsp;&nbsp;&nbsp; know what each other supports and what they do
not.<br>
<br>
&nbsp;&nbsp;&nbsp; Gestalt for non-mandatory features<br>
<br>
&nbsp; Large Block ciphers clarifications<br>
<br>
&nbsp; Suggestions?<br>
<br>
Advance to Draft, Collect $200<br>
&nbsp; 6 months have passed<br>
&nbsp; Requirements<br>
&nbsp;&nbsp;&nbsp; 2 implementations<br>
&nbsp;&nbsp;&nbsp; No IPR problems<br>
&nbsp;&nbsp;&nbsp; 6 months of experience<br>
<br>
&nbsp; JN: We have the experience but we do not have the
interoperability<br>
&nbsp; fully checked. Suggest: Enumerating all the musts and
publishing a</div>
<div>&nbsp; document so implementors can easily see requirements
for</div>
<div>&nbsp; compliance. Finally, we can get implementors into a room
for<br>
&nbsp; testing.<br>
</div>
<div>&nbsp; Implementors' survey &amp; results are at:</div>
<div>&nbsp;&nbsp;&nbsp; noc.rutgers.edu/~mione/ietf/ietfopgp.htm<span
></span>l<br>
</div>
<div>&nbsp; IMC (Internet Mail Consortium) maintains the OpenPGP <a
href="http://www.imc.org/ietf-open-pgp/mail-archive/">mailing list
archive</a>.</div>
<div>&nbsp; To subscribe and unsubscribe:<br>
&nbsp;&nbsp;&nbsp; List-subscribe:
&lt;mailto:[email-masked]?bo<span
></span>dy=subscribe&gt;<br>
&nbsp;&nbsp;&nbsp; List-Unsubscribe:
&lt;mailto:[email-masked]?bo<span
></span>dy=unsubscribe&gt;<br>
<br>
<br>
<br>
RFC2015 Revisions<br>
</div>
<div>&nbsp; Dave Del Torto</div>
<div>&nbsp;&nbsp;&nbsp; 1 outstanding item: 'Openpgp signed data'. 2
variations were<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; presented.</div>
<div>&nbsp;&nbsp;&nbsp; Variation 1 is from Tom Rossler. Variation 2
is the original</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; written by Dave Del Torto. The
main difference is that variation<br>
&nbsp;&nbsp;&nbsp; 1 leaves out md5 as a required hash for the
MICALG.<br>
</div>
<div>&nbsp;&nbsp;&nbsp; The consensus seemed to be we should remove
MUST for md5 hash in<br>
&nbsp;&nbsp;&nbsp; the MICALG.<br>
<br>
&nbsp;&nbsp;&nbsp; Discussion of parallel signatures. This is a way
of dividing a</div>
<div>&nbsp;&nbsp;&nbsp; message into multiparts and sign each
individually. Allows you to<br>
&nbsp;&nbsp;&nbsp; verify signatures independently. (This text is in
section 8 of the</div>
<div>&nbsp;&nbsp;&nbsp; new draft to be submitted today.)<br>
<br>
&nbsp;&nbsp;&nbsp; The aim at this time is that parallel signatures
will be OPTIONAL</div>
<div>&nbsp;&nbsp;&nbsp; in the revision to 2015.</div>
<div><br>
Summary<br>
</div>
<div>&nbsp;&nbsp;&nbsp; Misc question from audience. Will feature
packets be a MUST<br>
&nbsp;&nbsp;&nbsp; implement. JC: No.<br>
<br>
&nbsp;&nbsp;&nbsp; Action items<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jon Callas - New draft to replace
2440.<br>
&nbsp;&nbsp;<br>
</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tony Mione - enumerate MUSTs in
2440.</div>
<div><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dave, Thomas, Mike - New draft of
2015.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WG as a whole - WG last call on Son of
2440.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Son of 2015.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; before Nov.</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tony tentatively volunteered to
write a charter and call a bof</div>
<div
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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>
[email-masked]<br>
&nbsp; ----------------------------------------<span
></span>------------------------------<br>
&nbsp; The man that can most truly be accounted brave is he who
best<br>
&nbsp; knows the meaning of what is sweet in life and what is
terrible,<br>
&nbsp; and then goes out undeterred to meet what is to come.<br>
&nbsp; -- Pericles, &quot;Funeral Oration&quot;, 479 B.C.<br>
&nbsp; ----------------------------------------<span
></span>------------------------------</div>
</body>
</html>
--============_-1279027935==_ma============--

Date: Fri, 23 Jul 1999 12:36:07 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: Dave Del Torto <[email-masked]>
cc: Werner Koch <[email-masked]>, [email-masked]
Subject: Re: Oslo minutes?
Sender: [email-masked]

-----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
[email-masked]                        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
> 
> 

Date: Fri, 23 Jul 1999 10:20:31 -0500
To: Werner Koch <[email-masked]>
From: Dave Del Torto <[email-masked]>
Subject: Re: Oslo minutes?
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 23 Jul 1999 15:52:07 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Oslo minutes?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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

Date: Thu, 22 Jul 1999 16:35:35 -0700 (PDT)
To: [email-masked]
From: [email-masked]
Subject: Withdrawl
Sender: [email-masked]

Hi,

We were just notified that our purchased mail list
included;

[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]

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

Date: Thu, 22 Jul 1999 15:33:21 -0700 (PDT)
To: [email-masked]
From: [email-masked]
Subject: Buzzine Confirmation
Sender: [email-masked]

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

Date: Wed, 21 Jul 1999 19:03:56 -0700
To: Michael Elkins <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: OpenPGP conformance : MUSTS found in RFC2440
Sender: [email-masked]

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

Date: Wed, 21 Jul 1999 23:27:46 +0100
To: [email-masked]
CC: [email-masked]
From: Adam Back <[email-masked]>
Subject: compression & interoperability (Re: OpenPGP conformance : MUSTS found in RFC2440)
Sender: [email-masked]

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

Date: Wed, 21 Jul 1999 14:46:25 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Error in 5.2.3.22
Sender: [email-masked]

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

Date: Wed, 21 Jul 1999 14:35:38 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Preference Conformance
Sender: [email-masked]

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

Date: Wed, 21 Jul 1999 14:43:02 -0700
From: Michael Elkins <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP conformance : MUSTS found in RFC2440
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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

Date: Wed, 21 Jul 1999 14:03:46 -0700
To: Michael Elkins <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: OpenPGP conformance : MUSTS found in RFC2440
Sender: [email-masked]

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

Date: Wed, 21 Jul 1999 12:34:43 -0700
From: Michael Elkins <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP conformance : MUSTS found in RFC2440
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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

Date: Wed, 21 Jul 99 14:14 +0200
From: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
To: [email-masked]
Subject: Re: OpenPGP conformance : MUSTS found in RFC2440
Newsgroups: ulf.open-pgp
Organization: HR13
Cc: [email-masked]
Sender: [email-masked]

>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.

Date: Tue, 20 Jul 1999 18:05:27 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: OpenPGP conformance : MUSTS found in RFC2440
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 20 Jul 1999 [email-masked] wrote:

> Tony Mione, <[email-masked]>, 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
[email-masked]                        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

From: [email-masked]
Date: Tue, 20 Jul 1999 14:45:17 -0700
To: [email-masked], [email-masked]
Subject: Re: OpenPGP conformance : MUSTS found in RFC2440
Sender: [email-masked]

Tony Mione, <[email-masked]>, 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

Date: Tue, 20 Jul 1999 17:09:08 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: [email-masked]
cc: Tony Mione <[email-masked]>
Subject: OpenPGP conformance : MUSTS found in RFC2440
Sender: [email-masked]

-----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
[email-masked]                        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

From: Sayeh Sadat <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
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
Sender: [email-masked]

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 :
           [email-masked] ( Please use this one that is full =
graphic )
           [email-masked]
           [email-masked]
           [email-masked]
           [email-masked]

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>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; 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 &quot; Sharif University Of Technology &quot; of Iran .=20
</FONT><FONT color=3D#000000 size=3D2>My final project is about &quot;=20
<STRONG><EM><U>Public Key Cryptography</U></EM></STRONG> &quot; and I am =
looking=20
for any kind of information relative to this topic .</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; 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>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; 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>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Yours Faithfully ,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;--Sayeh Sadat--</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT size=3D2>Phone :</FONT></DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
</FONT><FONT size=3D2>98-</FONT><FONT size=3D2>21-</FONT><FONT=20
size=3D2>2547364</FONT></DIV>
<DIV>&nbsp;<FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
98-21-2549378</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Email :</FONT></DIV>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<A href=3D"mailto:[email-masked]">[email-masked]</A> ( =
Please use=20
this one that is full graphic )</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =

href=3D"mailto:[email-masked]">[email-masked]</A></FONT=
></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<A =
href=3D"mailto:[email-masked]">[email-masked]</A></FONT></DIV=
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<A=20
href=3D"mailto:[email-masked]">[email-masked]</A></FO=
NT></DIV></DIV>
<DIV><FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =

href=3D"mailto:[email-masked]">[email-masked]</A></FONT=
></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Mail Address=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Sayeh=20
Sadat</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2ND FL=20
#49</FONT></DIV>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
GHOLAMREZA RAHMANI ST.</FONT></DIV>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DIBAJI JONUBI ST.</FONT></DIV>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DOLAT AVE.</FONT></DIV>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
19598 TEHRAN&nbsp;</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
IRAN&nbsp;</FONT></DIV>
<DIV><BR></DIV></DIV></BODY></HTML>

------=_NextPart_000_0012_01BED213.A23A64A0--

Organization: ESAT, K.U.Leuven, Belgium
Date: Wed, 14 Jul 1999 16:10:30 +0200 (METDST)
From: "CMS'99" <[email-masked]>
To: Communications and Multimedia Security 1999 <[email-masked]>
Subject: CMS'99 - Communications and Multimedia Security
Sender: [email-masked]

[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 

-----------------------------------------------------------------------

Date: Wed, 14 Jul 1999 04:09:57 +0200
To: Will Price <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: PGP 6.5.1 - word list and SDAs?
Cc: [email-masked]
Sender: [email-masked]

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)
[email-masked]
   ----------------------------------------------------------------------
   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.
   ----------------------------------------------------------------------

Date: Mon, 12 Jul 1999 22:51:08 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: Key expiration
Sender: [email-masked]

Jon Callas <[email-masked]>:
> 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.

Date: Tue, 13 Jul 1999 00:39:56 +0200
To: OpenPGP mailing list <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Meeting in Oslo is ON!
Sender: [email-masked]

--============_-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)
[email-masked]
   ----------------------------------------------------------------------
   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>&nbsp; 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.&nbsp; 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.&nbsp; 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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>V5 Signatures</font></div>
<div><font
color="#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>MDC Data packet</font></div>
<div><font
color="#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Encryption Mode Normalization<br>
<x-tab>&nbsp;&nbsp; </x-tab>Features subpackets<i><b><br>
</b></i><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Gestalt for non mandatory features</font></div>
<div><font
color="#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Large Block Block ciphers clarifications</font></div>
<div><font
color="#000000"><i><b><x-tab
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </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 &amp; 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&nbsp; Jon
Callas and I are the only ones who show.&nbsp; I know Jon will be
there because I tackled him in the hall today and wouldn't let him go
until he promised.&nbsp; 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... &lt;grin&gt;).</div>
<div><br></div>
<div>best,</div>

<div><br>
john noerenberg (in Oslo Jul 10-19, 1999)<br>
[email-masked]<br>
&nbsp; ----------------------------------------<span
></span>------------------------------<br>
&nbsp; The man that can most truly be accounted brave is he who
best<br>
&nbsp; knows the meaning of what is sweet in life and what is
terrible,<br>
&nbsp; and then goes out undeterred to meet what is to come.<br>
&nbsp; -- Pericles, &quot;Funeral Oration&quot;, 479 B.C.<br>
&nbsp; ----------------------------------------<span
></span>------------------------------</div>
</body>
</html>
--============_-1280303196==_ma============--

Date: Mon, 12 Jul 1999 09:55:04 +0100
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Key expiration
Sender: [email-masked]

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

Date: Sun, 11 Jul 1999 13:05:30 +0200
To: OpenPGP mailing list <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Meeting in Oslo is ON!
Cc: "Jeffrey I. Schiller" <[email-masked]>, [email-masked]
Sender: [email-masked]

Wednesday morning at 9am in Munch.  Agenda will follow.

See you there!

Date: Sat, 10 Jul 1999 06:52:45 +0200
To: Paul Koning <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: V5 signatures
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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.

Date: Fri, 9 Jul 1999 16:44:11 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Expiration dates (was: Rip Van Winkle awakes: meeting in Oslo?)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Bodo Moeller <[email-masked]> 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

Date: Fri, 9 Jul 1999 14:44:02 +0200
From: Bodo Moeller <[email-masked]>
To: Jon Callas <[email-masked]>, Bodo Moeller <[email-masked]>, [email-masked]
Subject: Re: Rip Van Winkle awakes: meeting in Oslo?
Sender: [email-masked]

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.

Date: Thu, 8 Jul 1999 23:39:48 -0700
To: [email-masked] (Bodo Moeller), [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Rip Van Winkle awakes: meeting in Oslo?
Sender: [email-masked]

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

Date: Thu, 8 Jul 1999 21:55:38 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: Rip Van Winkle awakes: meeting in Oslo?
Sender: [email-masked]

"John  W. Noerenberg" <[email-masked]>:

> 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.)

Date: Thu, 8 Jul 1999 21:05:24 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: PGP 6.5.1 - word list and SDAs?
Sender: [email-masked]

Will Price <[email-masked]>:

> 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.

Date: Thu, 8 Jul 1999 09:55:59 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: V5 signatures
Sender: [email-masked]

>>>>> "Jon" == Jon Callas <[email-masked]> 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

Date: Wed, 7 Jul 1999 23:44:39 -0700
To: "John  W. Noerenberg" <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: V5 signatures
Cc: "William H. Geiger III" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Wed, 7 Jul 1999 21:41:05 +0100
To: [email-masked]
CC: [email-masked]
From: Adam Back <[email-masked]>
Subject: Re: PGP 6.5.1 - word list and SDAs?
Sender: [email-masked]

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

From: "Salzman, Noah" <[email-masked]>
To: Jack Repenning <[email-masked]>, Thomas Roessler <[email-masked]>, [email-masked]
Subject: RE: PGP 6.5.1 - word list and SDAs?
Date: Wed, 7 Jul 1999 14:54:04 -0700 
Sender: [email-masked]

To the best of my knowledge, Jack is right.

--Noah--

-----Original Message-----
From: Jack Repenning [mailto:[email-masked]]
Sent: Wednesday, July 07, 1999 2:46 PM
To: Salzman, Noah
Cc: Thomas Roessler; [email-masked]
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            [email-masked]
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

Date: Wed, 07 Jul 1999 14:45:39 -0700
To: "Salzman, Noah" <[email-masked]>
From: Jack Repenning <[email-masked]>
Subject: RE: PGP 6.5.1 - word list and SDAs?
Cc: Thomas Roessler <[email-masked]>, [email-masked]
Sender: [email-masked]

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            [email-masked]
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

From: "Salzman, Noah" <[email-masked]>
To: Thomas Roessler <[email-masked]>, [email-masked]
Subject: RE: PGP 6.5.1 - word list and SDAs?
Date: Wed, 7 Jul 1999 11:53:41 -0700 
Sender: [email-masked]

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:[email-masked]]
Sent: Wednesday, July 07, 1999 2:15 AM
To: [email-masked]
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 <[email-masked]> -----

Date:         Tue, 6 Jul 1999 18:21:39 -0700
From: Cody Brownstein <[email-masked]>
Subject:      PGP 6.5.1 has been released
To: [email-masked]

<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
<[email-masked]>
-----

PGP Fingerprint:
291B 5051 B97F 8B30 49F8  A068 15CF 26D6 E4DE 5291

----- End forwarded message -----

Date: Wed, 7 Jul 1999 18:43:19 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: V5 signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

"John  W. Noerenberg" <[email-masked]> 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

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 07 Jul 1999 11:03:00 -0500
To: "John  W. Noerenberg" <[email-masked]>
Cc: Jon Callas <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: V5 signatures
Sender: [email-masked]

In <v04205504b3a8704d9f84@[199.106.106.131]>, on 07/07/99 
   at 12:07 PM, "John  W. Noerenberg" <[email-masked]> 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!! :)
---------------------------------------------------------------

Date: Wed, 07 Jul 1999 08:35:54 -0700
To: Thomas Roessler <[email-masked]>
From: Jack Repenning <[email-masked]>
Subject: Re: PGP 6.5.1 - word list and SDAs?
Cc: Will Price <[email-masked]>, [email-masked]
Sender: [email-masked]

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            [email-masked]
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

Date: Wed, 7 Jul 1999 12:07:33 +0900
To: Jon Callas <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: V5 signatures
Cc: "William H. Geiger III" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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
[email-masked]
   ----------------------------------------------------------------------
   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.
   ----------------------------------------------------------------------

Date: Wed, 7 Jul 1999 12:14:50 +0900
To: OpenPGP mailing list <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Rip Van Winkle awakes: meeting in Oslo?
Sender: [email-masked]

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
[email-masked]
   ----------------------------------------------------------------------
   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.
   ----------------------------------------------------------------------

Date: Wed, 7 Jul 1999 09:44:40 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: PGP 6.5.1 - word list and SDAs?
Sender: [email-masked]

>>>>> "Will" == Will Price <[email-masked]> 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: 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 <[email-masked]>
To: Will Price <[email-masked]>
Cc: [email-masked]
Subject: Re: PGP 6.5.1 - word list and SDAs?
Message-ID: <[email-masked]>
Mail-Followup-To: Will Price <[email-masked]>, [email-masked]
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
User-Agent: Mutt/0.96.3i
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[email-masked]?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.

Date: Wed, 07 Jul 1999 04:07:05 -0700
From: Will Price <[email-masked]>
To: [email-masked]
Subject: Re: PGP 6.5.1 - word list and SDAs?
Sender: [email-masked]

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.

>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 <[email-masked]>
To: [email-masked]
Subject: Re: PGP 6.5.1 - word list and SDAs?
Message-ID: <[email-masked]>
Mail-Followup-To: [email-masked]
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
User-Agent: Mutt/0.96.3i
In-Reply-To: <[email-masked]>
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: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[email-masked]?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.)

Date: Wed, 7 Jul 1999 12:08:05 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: PGP 6.5.1 - word list and SDAs?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Thomas Roessler <[email-masked]> 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

Date: Wed, 07 Jul 1999 02:38:43 -0700
From: Will Price <[email-masked]>
To: [email-masked]
Subject: Re: PGP 6.5.1 - word list and SDAs?
Sender: [email-masked]

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.

>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 <[email-masked]>
To: [email-masked]
Subject: PGP 6.5.1 - word list and SDAs?
Message-ID: <[email-masked]>
Mail-Followup-To: [email-masked]
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: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[email-masked]?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 <[email-masked]> -----

Date:         Tue, 6 Jul 1999 18:21:39 -0700
From: Cody Brownstein <[email-masked]>
Subject:      PGP 6.5.1 has been released
To: [email-masked]

<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
<[email-masked]>
-----

PGP Fingerprint:
291B 5051 B97F 8B30 49F8  A068 15CF 26D6 E4DE 5291

----- End forwarded message -----

Date: Fri, 2 Jul 1999 13:13:44 +0200 (CEST)
From: Patrick Feisthammel <[email-masked]>
Reply-To: Patrick Feisthammel <[email-masked]>
To: Marcel Waldvogel <[email-masked]>
cc: "William H. Geiger III" <[email-masked]>, [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

-----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 ([email-masked])    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

Date: Fri, 2 Jul 1999 11:02:09 +0200
From: Marcel Waldvogel <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

On Thu, Jul 01, 1999 at 09:27:28AM -0500, "William H. Geiger III" <[email-masked]> 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

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 01 Jul 1999 09:27:28 -0500
To: Marcel Waldvogel <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

In <[email-masked]>, on 07/01/99 
   at 12:54 AM, Marcel Waldvogel <[email-masked]> 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: 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 <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
User-Agent: Mutt/0.96.3i
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-open-pgp/mail-archive/>
List-Unsubscribe: <mailto:[email-masked]?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.