Subject: OpenPGP should be called ClosedPGP

From: Erron Criddle <[email-masked]>
Date: Sun, 25 Jun 2000 12:48:32 +0800

To all that can (well most):

Just e-mailing to say that I am appalled at the helpfulness of this list; I 
have been involved with the Internet for six years now and have also been 
involved with other standards, lists and discussion forums and this is the 
most "closed" list I have ever come across!

After literally many hours of research, I have come across only one 
document that explains part of 2440 in a understandable format and that is:

http://www.openpgp.net/pgpemail_toc.html

I have also noticed there is a book called:

OpenPGP Specification & Sample Code; ISBN: 1583680144; by Jon Callas...

however, upon e-mailing the author for instructions on how to obtain the 
book and visits to www.cryptography.org and www.pibooks.com to purchase it 
(found URL's in openpgp archives), I am still left wondering whether the 
book actually exists!

Come on people who are developing this standard - if you want it to take 
off, help people and/or make something available to people like me and 
other project directors so we can develop the OpenPGP standard and not get 
bogged down cryptanalysing the 2440 document into plain text!

PS: Thanks to those who have responded to my e-mails - it certainly has 
confirmed many things I was unsure of regarding OpenPGP.

PSS: Ignore this message if the MITM is blocking everyone's answers to my 
e-mails :)

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

---

From: Werner Koch <[email-masked]>
Date: Mon, 26 Jun 2000 17:46:19 +0200

> document that explains part of 2440 in a understandable format and that is:

OpenPGP is quite complex (but not as complex as some other protocols),
so it takes a while to understand all the details.  A lot of things
have been explained on this mailing list here more than one time. 
Have a look at the archives.  

And there are at least 3 implementations which you can consult to
check how a detail is actually done.

> off, help people and/or make something available to people like me and 

PGP is around for nearly a decade now.  OpenPGP is just an enhancement
on the PGP 2 data formats.

> bogged down cryptanalysing the 2440 document into plain text!

I think Jon did a fine job as editor of this document and to me it is
an easy to understand specification.

  Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel +49 211 239577-0
Birkenstr. 12                           email   [email-masked]
D-40233 Duesseldorf                     http://www.OpenIT.de

---

From: Thomas Roessler <[email-masked]>
Date: Mon, 26 Jun 2000 18:00:22 +0200

On 2000-06-26 17:46:19 +0200, Werner Koch wrote:

> PGP is around for nearly a decade now.  OpenPGP is just
> an enhancement on the PGP 2 data formats.

Actually, it might be instructive to first try to
understand the considerably simpler PGP 2 data formats as
documented in the pgformat.doc file which comes with PGP
2.

---

From: Erron Criddle <[email-masked]>
Date: Tue, 27 Jun 2000 09:13:29 +0800

Werner,

>an easy to understand specification.

I also think Jon did a fine job on the document, however for a newcomer to 
implement PGP, something else is needed - it can be a challenge to "put it 
together" when you have no experience with PGP at all :)

As I am understanding the 2440bis, I am also creating another document that 
could possibly be useful to others like me in the future.

Thanks for the reply.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

---

From: Erron Criddle <[email-masked]>
Date: Tue, 27 Jun 2000 09:16:18 +0800

Thomas,

>documented in the pgformat.doc file which comes with PGP

That document was very informative and certainly helped me gain a better 
understanding of PGP.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

---

From: [email-masked]
Date: Tue, 27 Jun 2000 11:34:32 +0900

From: Werner Koch <[email-masked]>
Subject: Re: OpenPGP should be called ClosedPGP
Date: Mon, 26 Jun 2000 17:46:19 +0200
Message-ID: <[email-masked]>

> check how a detail is actually done.

regarding this point, i don't think it is good to suggest this in
general because of potential problems if the potential implementor
wants to create an independent implementation.  or do you think this
is an unnecessary precaution?

---

From: Werner Koch <[email-masked]>
Date: Wed, 28 Jun 2000 10:50:18 +0200

> wants to create an independent implementation.  or do you think this

Well, I have not looked at any other implemenation for writing GnuPG;
becuase the GNU coding standards demands this and it may have caused 
legal problems with NAI.  However, you can ask someone other to analyze
the behaviour of one implemenation and write a report on this. 

  Werner

---

From: [email-masked]
Date: Wed, 28 Jun 2000 19:43:42 +0900

From: Werner Koch <[email-masked]>
Subject: Re: OpenPGP should be called ClosedPGP
Date: Wed, 28 Jun 2000 10:50:18 +0200
Message-ID: <[email-masked]>

> legal problems with NAI.  

right, this could happen w/ other implementations as well if people
are not careful.  

if it wasn't already obvious, i really really really appreciate your
work on gnupg!  besides being a user, i am glad that there are
multiple implementations of openpgp (speaking of which, would it be
possible to list urls for existing implementations on the page for the
working group at:

  http://www.imc.org/ietf-openpgp/

?)

> However, you can ask someone other to analyze the behaviour of one
> implemenation and write a report on this.

that's true, but i think that may likely take more time than is actually
necessary -- what are standards for afterall?  however, i agree that the
method you suggest can be useful.

imo, open standard documents should be made clear and easy to
understand, particular those dealing w/ security since
misunderstandings can have serious consequences --
e.g. misimplementations.

i did not find the openpgp document to be particularly easy to
understand (e.g. wording, order of introducing terms, etc.).  i do not
intend this as an attack on any of the authors or editors so i hope
people will not take it as such.  i just want to voice my opinion as
someone who has read (and who rereads) the document.

i would be quite happy to go through the document and offer
suggestions on wording and such toward the end of making it easier to
digest.

---

From: Ulf Möller <[email-masked]>
Date: Wed, 28 Jun 2000 19:03:23 -0400

> someone who has read (and who rereads) the document.

I have to agree with this. I started working on my implementation
while OpenPGP was still a draft, and it would have been impossible
to write it with only the information in the OpenPGP document. The
situation has improved a bit, but there are a lot of problems left.

---

From: Werner Koch <[email-masked]>
Date: Thu, 29 Jun 2000 11:31:55 +0200

> to write it with only the information in the OpenPGP document. The

As stated in rfc2440, it is based on rfc1991 which is much simpler
becuase it describes the protocol used by PGP 2.  As Thomas already 
mentioned, it is advisable to read other (cited) texts too. 
Especially I think it is impossible to write an implemention without 
the HAC or similiar information.

  Werner

---

From: [email-masked]
Date: Thu, 29 Jun 2000 19:46:36 +0900

From: Werner Koch <[email-masked]>
Subject: Re: OpenPGP should be called ClosedPGP
Date: Thu, 29 Jun 2000 11:31:55 +0200
Message-ID: <[email-masked]>

> mentioned, it is advisable to read other (cited) texts too. 

it's probably up to ulf to clarify what he meant, but from the quoted
context in his post, i did not interpret his statement to mean that
one should be able to implement openpgp w/o looking at the references
mentioned in the openpgp document.  i think the point is that some
people feel that the existing document can be improved in certain
ways.

i'd like to work on improving the existing document so that it is
clearer and easier to understand.  is the working group amenable to
this?

---

From: Werner Koch <[email-masked]>
Date: Thu, 29 Jun 2000 15:41:19 +0200

> clearer and easier to understand.  is the working group amenable to

IMHO it is more important to "proceed" with ineroperability test, so
that we can move to draft standard ...

  Werner

---

From: Andrea Liles <[email-masked]>
Date: Thu, 29 Jun 2000 10:14:07 -0400

At 07:43 PM 6/28/00 +0900, you wrote:

...

...

I would find it quite useful to have a comprehensive list of existing 
implementations. If there is another location please advise.

Thank you,

Andrea

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Andrea Liles
Director
Information Guardian International, Ltd.
3000 Technology Campus, The Valley, Anguilla TV1 02P
British West Indies
Public Keys at:
http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0x46914066
http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0xD6D84395
http://horowitz.surfnet.nl:11371/pks/lookup?op=get&search=0x46914066
http://horowitz.surfnet.nl:11371/pks/lookup?op=get&search=0xD6D84395
RSA 1BE5 856B 4FF7 6E79  7E2B DF01 94FB 58FD
DSS  CA8F E2B6 9D1B 0699 8DD5  CFE5 29F1 5075 4691 4066
  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

---

From: [email-masked]
Date: Fri, 30 Jun 2000 09:28:23 +0900

From: Werner Koch <[email-masked]>
Subject: Re: OpenPGP should be called ClosedPGP
Date: Thu, 29 Jun 2000 15:41:19 +0200
Message-ID: <[email-masked]>

> that we can move to draft standard ...

that's consistent w/ the impression i get from some other members of
the wg (implicitly and explicitly) -- though it may just be all in my
head ;-)

i have a question regarding moving to draft standard that i hope
someone can answer.  once that happens, is it possible to make any
changes to the specification document?  i.e. is it possible to make
the kinds of changes that are specifically designed to make the
document clearer and easier to understand, and get those changes
reflected w/o issuing a new standard?

alternatively, is there ever a time that is appropriate for
making/suggesting those kinds of changes?

---

From: Ulf Möller <[email-masked]>
Date: Thu, 29 Jun 2000 19:27:57 -0400

On Thu, Jun 29, 2000 at 07:46:36PM +0900, [email-masked] wrote:

> mentioned in the openpgp document.

Right. I assumed the purpose of references was obvious. :)

If a document is supposed to become a standard, it should contain -
directly or through references - the information required to build an
interoperable implementation. I maintain that that is not the case,
the fact that Werner personally didn't look at the PGP source code
nonwithstanding.

Preferrably the document would also present the information in an
easily accessible way, but it would already be a good step if only the
issues raised on this list in the past would finally be addressed.

---

From: Erron Criddle <[email-masked]>
Date: Fri, 30 Jun 2000 10:26:19 +0800

Sen,

>clearer and easier to understand.  is the working group amenable to

Although implementation testing is very important and would require 2440bis 
to remain reasonably static for the that to happen, it may be possible to 
also implement a document in parallel that accompanies 2440 and would be 
basically targeted at the implementor. This doc could provide 
implementation guidelines in a "summarised" fashion and would refer to 2440 
for further understanding.

Basically it would be targeted at implementors that are starting from scratch.

One possible way to move ahead with this document is to make an FTP site 
available so that anybody could upload their own "summaries" or 
implementation notes. From this, we can then consolidate the information 
and create another doc that is a basic guideline for implementing OpenPGP.

If peoples are interested, let me know and I'll set up an FTP site so notes 
etc etc can be uploaded for others to view for comment.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

Date: Fri, 30 Jun 2000 10:26:19 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Implementation doc.
Cc: [email-masked]
Sender: [email-masked]

Sen,

>clearer and easier to understand.  is the working group amenable to

Although implementation testing is very important and would require 2440bis 
to remain reasonably static for the that to happen, it may be possible to 
also implement a document in parallel that accompanies 2440 and would be 
basically targeted at the implementor. This doc could provide 
implementation guidelines in a "summarised" fashion and would refer to 2440 
for further understanding.

Basically it would be targeted at implementors that are starting from scratch.

One possible way to move ahead with this document is to make an FTP site 
available so that anybody could upload their own "summaries" or 
implementation notes. From this, we can then consolidate the information 
and create another doc that is a basic guideline for implementing OpenPGP.

If peoples are interested, let me know and I'll set up an FTP site so notes 
etc etc can be uploaded for others to view for comment.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

Date: Thu, 29 Jun 2000 19:27:57 -0400
From: =?iso-8859-1?Q?Ulf_M=F6ller?= <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: OpenPGP should be called ClosedPGP
Sender: [email-masked]

From: [email-masked]
To: [email-masked]
Subject: Re: OpenPGP should be called ClosedPGP
Date: Fri, 30 Jun 2000 09:28:23 +0900
Lines: 27
Sender: [email-masked]

Date: Thu, 29 Jun 2000 10:14:07 -0400
To: [email-masked]
From: Andrea Liles <[email-masked]>
Subject: Re: OpenPGP should be called ClosedPGP
Sender: [email-masked]

...

...

Thank you,

Andrea

Date: Thu, 29 Jun 2000 15:41:19 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP should be called ClosedPGP
Mail-Followup-To: [email-masked]
Sender: [email-masked]

  Werner

From: [email-masked]
To: [email-masked]
Subject: Re: OpenPGP should be called ClosedPGP
Date: Thu, 29 Jun 2000 19:46:36 +0900
Lines: 28
Sender: [email-masked]

Date: Thu, 29 Jun 2000 11:31:55 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP should be called ClosedPGP
Mail-Followup-To: [email-masked]
Sender: [email-masked]

  Werner

Date: Wed, 28 Jun 2000 19:03:23 -0400
From: =?iso-8859-1?Q?Ulf_M=F6ller?= <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: OpenPGP should be called ClosedPGP
Sender: [email-masked]

From: [email-masked]
To: [email-masked]
Subject: Re: OpenPGP should be called ClosedPGP
Date: Wed, 28 Jun 2000 19:43:42 +0900
Lines: 52
Sender: [email-masked]

?)

Date: Wed, 28 Jun 2000 10:50:18 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP should be called ClosedPGP
Mail-Followup-To: [email-masked]
Sender: [email-masked]

  Werner

From: [email-masked]
To: [email-masked]
Subject: Re: OpenPGP should be called ClosedPGP
Date: Tue, 27 Jun 2000 11:34:32 +0900
Lines: 12
Sender: [email-masked]

Date: Tue, 27 Jun 2000 09:16:18 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Re: OpenPGP should be called ClosedPGP
Cc: Thomas Roessler <[email-masked]>
Sender: [email-masked]

Thomas,

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

Date: Tue, 27 Jun 2000 09:13:29 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Re: OpenPGP should be called ClosedPGP
Cc: Werner Koch <[email-masked]>
Sender: [email-masked]

Werner,

Thanks for the reply.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

Date: Tue, 27 Jun 2000 09:34:13 +1000
To: [email-masked]
From: Michael Walker <[email-masked]>
Subject: Perl/CGI integration??
Sender: [email-masked]

I'm fairly new to the OpenPGP concept so please forgive me if I'm ignorant.

Is there a way to encrypt an email using OpenPGP (or any other encryption 
method), where the email is generated by a Perl script calling sendmail?

Any help is greatly appreciated.

Thanks,
Michael Walker
-------------------------------------------------------------------
Michael Walker
	+ Balance Infosystems
	+ Pentacles Music
	+ WarmPond
	- IT Programmer
		ABN    : 42 885 500 249
		Mobile : (+61) 0413 273 435
		E-mail  : [email-masked]
		WWW  : http://www.wildfire-music.com.au/djnektie
		ICQ     : 66056756
-------------------------------------------------------------------

Date: Mon, 26 Jun 2000 18:00:22 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP should be called ClosedPGP
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Date: Mon, 26 Jun 2000 17:46:19 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP should be called ClosedPGP
Mail-Followup-To: [email-masked]
Sender: [email-masked]

  Werner

Date: Sun, 25 Jun 2000 12:48:32 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: OpenPGP should be called ClosedPGP
Sender: [email-masked]

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

From: [email-masked]
To: [email-masked]
Subject: Re: V4 signature Q
Date: Fri, 23 Jun 2000 21:33:12 +0900
Lines: 33
Sender: [email-masked]

From: Erron Criddle <[email-masked]>
Subject: V4 signature Q
Date: Fri, 23 Jun 2000 18:03:40 +0800
Message-ID: <[email-masked]>

> Regarding a V4 signature;
> 
> 5.2.3 states that the third octec of a signature contains the public key 
> algorithm. Would it be correct for me to say that the values of the 3rd 
> octec of a signature packet can contain either:
> 
> 	1   - RSA (Encrypt or sign)
> 	3   - RSA (sign only)
> 	17 - DSA
> 	20 - ElGamal (encrypt or sign)
> 
> I'm trying to work out where the digital signature algorithm is specified 
> in the signature and this is the only place I can see it fitting.

the location looks correct to me for specifying the public key
algorithm portion of specifying the method of computation of the
digital signature.  i think the hash algorithm is also relevant as it
is also part of the process of computing a signature...but it's the
next octet over anyway ;-)

note the comment in section 12.4 regarding rsa sign-only keys that
says:

   There are algorithm types for RSA-signature-only, and RSA-encrypt-
   only keys. These types are deprecated. The "key flags" subpacket in a
   signature is a much better way to express the same idea, and
   generalizes it to all algorithms. An implementation SHOULD NOT create
   such a key, but MAY interpret it.

Date: Fri, 23 Jun 2000 18:03:40 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: V4 signature Q
Sender: [email-masked]

I was wondering if someone could please clarify something (again :) :

Regarding a V4 signature;

5.2.3 states that the third octec of a signature contains the public key 
algorithm. Would it be correct for me to say that the values of the 3rd 
octec of a signature packet can contain either:

	1   - RSA (Encrypt or sign)
	3   - RSA (sign only)
	17 - DSA
	20 - ElGamal (encrypt or sign)

I'm trying to work out where the digital signature algorithm is specified 
in the signature and this is the only place I can see it fitting.

thank you in advance for any answers...

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

Date: Fri, 23 Jun 2000 00:07:57 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: Bodo Moeller <[email-masked]>
cc: [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

On Fri, 23 Jun 2000, Bodo Moeller wrote:

> On Thu, Jun 22, 2000 at 01:37:49PM -0700, L. Sassaman wrote:
> > On Mon, 19 Jun 2000, Bodo Moeller wrote:
> >> L. Sassaman <[email-masked]>:
> 
> >>> [...]  Expanding from the right is less natural to users whose language
> >>> reads from left to right, in my opinion.
> 
> >> Have you used a telephone lately?
> 
> > That's a non sequitor if I have ever seen one...
> 
> Dialing certain postfixes of a given phone number can work, dialing
> any prefix won't.  That is, phone numbers expand from the right.
> I haven't yet heard of anyone complaing about this on the grounds that
> thear language reads from left to right.

That's an invalid analogy. Telephone prefixes exist so that phone numbers
can be grouped seperately. There is no such grouping with OpenPGP key
ideas -- all key ids are members of one group. In a left to right
most-significant-bit key id expansion, if the 32 or 64 bits you provided
weren't enough, you could keep adding more until a match was found. In a
left to right least-signification-bit expansion, you would have to start
over with the new information.

This is all academic, however, since I think we decided that changing this
now would be worse than leaving it the way it is.

__

L. Sassaman

System Administrator                |  "If you chose not to decide, 
Technology Consultant               |  you still have made a choice" 
icq.. 10735603                      |  
pgp.. finger://ns.quickie.net/rabbi |                    --Rush

Date: Fri, 23 Jun 2000 07:59:55 +0200
From: [email-masked] (Bodo Moeller)
To: "L. Sassaman" <[email-masked]>
Cc: Bodo Moeller <[email-masked]>, [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

On Thu, Jun 22, 2000 at 01:37:49PM -0700, L. Sassaman wrote:
> On Mon, 19 Jun 2000, Bodo Moeller wrote:
>> L. Sassaman <[email-masked]>:

>>> [...]  Expanding from the right is less natural to users whose language
>>> reads from left to right, in my opinion.

>> Have you used a telephone lately?

> That's a non sequitor if I have ever seen one...

Dialing certain postfixes of a given phone number can work, dialing
any prefix won't.  That is, phone numbers expand from the right.
I haven't yet heard of anyone complaing about this on the grounds that
thear language reads from left to right.

From: [email-masked]
To: [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Date: Fri, 23 Jun 2000 11:16:25 +0900
Lines: 23
Sender: [email-masked]

From: "L. Sassaman" <[email-masked]>
Subject: Re: KeyID as left vs right substring of fingerprint
Date: Thu, 22 Jun 2000 13:37:49 -0700 (PDT)
Message-ID: <[email-masked]>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Mon, 19 Jun 2000, Bodo Moeller wrote:
> 
> > L. Sassaman <[email-masked]>:
> > 
> > > [...]  Expanding from the right is less natural to users whose language
> > > reads from left to right, in my opinion.
> > 
> > Have you used a telephone lately?
> 
> That's a non sequitor if I have ever seen one...

i didn't understand the remark about the telephone.  does it have to
do w/ a touch pad or display or numbers on a screen?

perhaps the original poster could elaborate?

Date: Thu, 22 Jun 2000 13:37:49 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: Bodo Moeller <[email-masked]>
cc: [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

On Mon, 19 Jun 2000, Bodo Moeller wrote:

> L. Sassaman <[email-masked]>:
> 
> > [...]  Expanding from the right is less natural to users whose language
> > reads from left to right, in my opinion.
> 
> Have you used a telephone lately?

That's a non sequitor if I have ever seen one...

__

L. Sassaman

System Administrator                |  "If you chose not to decide, 
Technology Consultant               |  you still have made a choice" 
icq.. 10735603                      |  
pgp.. finger://ns.quickie.net/rabbi |                    --Rush

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Revised MDC packet spec
Date: Thu, 22 Jun 2000 14:28:35 -0400
Sender: [email-masked]

>Or maybe we should just do the sync anyway.

I would normally be in favor maintaining the traditional resync,
since it's code any implementation has to have anyway, but here
it would open up a huge hole.  An attacker could easily convert a
new SEIP data packet into an old SE data packet by replacing the
header+version and tearing off the known-sized MDC packet at the end.
Depending on the difference in resync mode alone doesn't feel good
to me, though.

Perhaps Hal could elaborate on the internal discussions that
motivate including the block+2 pad in the hash.

If you don't need the block+2 pad in the hash, then you could just
use another level of nested packet, something like:
    Symmetrically-Encrypted-Packet {
        block+2 pad
 MDC-packet {
     arbitrary-packet // compressed or literal
     hash
 }
    }

I would find another nesting level much easier to implement in
a pipelined receiver.  To implement the latest (non-nested) proposal,
an inner packet-parsing loop would need access to context from the
outer reading logic, which is not nearly as natural.

Looking through the archive, I see Tom Zerucha proposed bracketing
with two new packets, but I haven't seen this nested approach mentioned.
It's quite possible I've just missed it -- there's been a lot for
me to catch up on -- so if it's been discussed, can someone point
me at the messages?

From: [email-masked]
To: [email-masked]
Subject: Re: Do sigs. on encoded data confirm to OpenPGP?
Date: Wed, 21 Jun 2000 11:52:01 +0900
Lines: 15
Sender: [email-masked]

From: Erron Criddle <[email-masked]>
Subject: Do sigs. on encoded data confirm to OpenPGP?
Date: Tue, 20 Jun 2000 17:06:51 +0800
Message-ID: <[email-masked]>

> Has anyone thought about this:
> 
> If I am to produce a signature on a 100 MByte file (for example), unless I 
> produce the signature from the encrypted (and encoded?) file, the receiver 
> would have to decrypt the entire 100MByte file just to verify a signature 
> that may be invalid!

i'm a little fuzzy at this time of day, but isn't there some sort of
attack that's possible if you sign some encrypted data?  perhaps someone
else who is more awake can confirm ;-)

Date: Tue, 20 Jun 2000 08:41:05 -0400
From: "Michael H. Warfield" <[email-masked]>
To: Erron Criddle <[email-masked]>
Cc: [email-masked]
Subject: Re: Quick Triple-DES Q
Sender: [email-masked]

On Mon, Jun 05, 2000 at 12:30:59PM +0800, Erron Criddle wrote:
> To all,

> Has RSA allowed a royalty/payment free use of the Triple-DES algorithm for 
> use in the OpenPGP standard?

	AFAIK, RSA has no IP encumberances on DES or 3-DES what so ever.
The patent on the RSA algorithm expires in a few months at which time
RSA labs loses their IP encumberance on that.

> TIA.

-- 
 Michael H. Warfield    |  (770) 985-6132   |  [email-masked]
  (The Mad Wizard)      |  (770) 331-2437   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

To: [email-masked]
Subject: Signature subpacket clarification
From: Florian Weimer <[email-masked]>
Date: 20 Jun 2000 15:09:37 +0200
Lines: 38
Sender: [email-masked]

The phrase "MUST be present in the hashed area." has to be added to
the following sections:

5.2.3.4. Signature creation time
5.2.3.6. Key expiration time
5.2.3.10. Signature expiration time
5.2.3.12. Revocable
5.2.3.13. Trust signature
5.2.3.14. Regular expression
5.2.3.15. Revocation key
5.2.3.17. Key server preferences
5.2.3.19. Primary user id
5.2.3.21. Key Flags
5.2.3.22. Signer's User ID
5.2.3.23. Reason for Revocation

I'm not sure about the following (GnuPG puts them into the hashed
area):

5.2.3.7. Preferred symmetric algorithms
5.2.3.8. Preferred hash algorithms
5.2.3.9. Preferred compression algorithms

Hash protection is obviously not needed for:

5.2.3.5. Issuer
5.2.3.11. Exportable Certification
5.2.3.18. Preferred key server (resolving URLs isn't secure anyway)
5.2.3.20. Policy URL (ditto)

Whether notation data has to be put into the hashed area depends on
that data, of course.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5

Date: Tue, 20 Jun 2000 17:06:51 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Do sigs. on encoded data confirm to OpenPGP?
Sender: [email-masked]

Has anyone thought about this:

If I am to produce a signature on a 100 MByte file (for example), unless I 
produce the signature from the encrypted (and encoded?) file, the receiver 
would have to decrypt the entire 100MByte file just to verify a signature 
that may be invalid!

Would it be possible (to alleviate this situation), to:

1) Compress Plaintext
2) Encrypt Plaintext
3) Encode the file (if necessary)
4) Produce Signature
5) Encrypt Signature (using same session key as in 2?)
6) Encrypt session key using receiver's public key.

Detached signatures are mentioned in 10.3 from 2440 that may address this 
situation, however there are no specific details on this methodology.

When the e-mail is received, the following would occur:

1) Decryption of session key (using private key)
2) Decryption of signature (using private key)
3) Run hashing algorithm and DSA over the encrypted/encoded data
4) Compare sigs and either discard or decrypt to the original plaintext.

This way, the receiver doesn't have to decrypt a 100 MByte file just to 
verify a signature that may be invalid! I know you can use a single pass 
signature to speed up the process of decryption etc, however you still have 
to decrypt to the original plain-text and that seems to be a waste of time 
if the sigs don't match.

If someone could advise on a solution they may have come across whereby you 
do not have to decrypt/decode just to verify a signature, it would be much 
appreciated.

TIA.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

Date: Tue, 20 Jun 2000 09:20:57 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Open-PGP Q re DSA and keys > 1024 bit
Sender: [email-masked]

To all,

Upon reading 2440bis re DSA and a ElGamal key length limit of 1024 bits, I 
was wondering what the Open-PGP group recommends for signing if you use 
ElGamal keys > 1024 bits?

If you do use ElGamal Keys > 1024 bits, should you have another set of keys 
<=1024 bits for signing or is there a standard way to reduce 2048 bit PGP 
keys down to 1024 bits suitable for the DSA signature algorithm?

TIA for any info.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

Date: Mon, 19 Jun 2000 16:45:48 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

L. Sassaman <[email-masked]>:

> [...]  Expanding from the right is less natural to users whose language
> reads from left to right, in my opinion.

Have you used a telephone lately?

Date: Sat, 17 Jun 2000 01:25:24 -0400
From: Tom Zerucha <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Revised MDC packet spec
Sender: [email-masked]

On Fri, Jun 16, 2000 at 05:38:28PM -0700, Jon Callas wrote:
> Or maybe we should just do the sync anyway.
> 
> It's one thing to not be standard, but it's another to not be consistent.
> The only thing that one can complain about PGP-CFB for is that it's not
> standard CFB. I don't see that as an issue.
> 
> Other systems, like CMS, use CBC mode not CFB at all, so we're no less
> different even if we switch.
> 
> I would prefer to keep one encryption mode and use it everywhere. The one
> to use, is of course PGP-CFB. However, if we're going to change it, we
> should discuss using CBC mode.

I agree with this since I separate the operators from the core, though
cfb mode is one of the standard calls in openssl.  For all else I have
a cfbomatic routine.

However wasn't there something about NOT resetting if the block length
for the cipher was over 9 bytes in length?

Let me bring up another consideration (while looking for the above).

3.6.2.1...

   These are followed by an 8-octet Initial Vector for the decryption of
   the secret values, if they are encrypted, and then the secret key
   values themselves.

5.5.3...

     - [Optional] If secret data is encrypted, eight-octet Initial
       Vector (IV).

and

   With V3 keys, the MPI bit count prefix
   (i.e., the first two octets) is not encrypted.  Only the MPI non-
   prefix data is encrypted.  Furthermore, the CFB state is
   resynchronized at the beginning of each new MPI value, so that the
   CFB block bou

The symmetric ciphers are used more than one place - one is for
unlocking secret keys, and we have resyncs here.

So what happens for secret keys using a cipher with a 128 bit block
size?  Do we use 16 octet IVs?  Do we resync on mpi boundaries for a
V3 key (is this possible - I don't see anywhere in the spec where it
says you MUST use IDEA to encrypt V3 secret key material)?

(Actually I have a problem in my current opgp implementation since I
don't support block sizes other than 8 bytes (no, I refuse to always
use "octet"), but as soon as I can get the new algorithms going I know
where and how to fix it).

Date: Fri, 16 Jun 2000 17:38:28 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Revised MDC packet spec
Sender: [email-masked]

Or maybe we should just do the sync anyway.

It's one thing to not be standard, but it's another to not be consistent.
The only thing that one can complain about PGP-CFB for is that it's not
standard CFB. I don't see that as an issue.

Other systems, like CMS, use CBC mode not CFB at all, so we're no less
different even if we switch.

I would prefer to keep one encryption mode and use it everywhere. The one
to use, is of course PGP-CFB. However, if we're going to change it, we
should discuss using CBC mode.

	Jon

From: [email-masked]
Date: Fri, 16 Jun 2000 14:40:07 -0700
To: [email-masked], [email-masked]
Subject: Re: Revised MDC packet spec
Sender: [email-masked]

Tom writes, quoting Werner:
> > One suggestion:  Add a note that the old PGP sync mode is not used with
> > the wew packet 18.  
>
> Did I miss something?  The description of the new type 18 packet
> indicates a prefix that looks like the PGP-sync prefix used elsewhere.
>
> But I didn't see the resync operation that is done everywhere else (I
> didn't read that carefully).
>
> So if I understand correctly, we are going to use the prefix but NOT
> going to do the resync?

That's correct.  This is for two reasons: one is that the sync is nonstandard
and has caused problems.  Perhaps someday we can deprecate the old symmetric
encryption packet and eliminate the sync altogether.  The second reason is
to make the encrypted data in these packets more different from the data in
the old packets, making it less likely that an attacker could turn a new
packet into an old one.

Maybe as Werner said the spec should have an explicit note confirming that
the sync is not done in this packet.

Hal

Date: Fri, 16 Jun 2000 16:53:09 -0400
From: Tom Zerucha <[email-masked]>
To: [email-masked]
Subject: Re: Revised MDC packet spec
Sender: [email-masked]

On Fri, Jun 16, 2000 at 09:42:34AM +0200, Werner Koch wrote:
> Hi, 
> 
> On Thu, 15 Jun 2000, [email-masked] wrote:
> 
> > Based on internal discussions we would like to make a small change to
> > the Symmetrically Encrypted Integrity Protected Data Packet format.
> 
> This is fine with me.  
> 
> One suggestion:  Add a note that the old PGP sync mode is not used with
> the wew packet 18.  

Did I miss something?  The description of the new type 18 packet
indicates a prefix that looks like the PGP-sync prefix used elsewhere.

But I didn't see the resync operation that is done everywhere else (I
didn't read that carefully).

So if I understand correctly, we are going to use the prefix but NOT
going to do the resync?

Date: Fri, 16 Jun 2000 09:42:34 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Revised MDC packet spec
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi, 

On Thu, 15 Jun 2000, [email-masked] wrote:

> Based on internal discussions we would like to make a small change to
> the Symmetrically Encrypted Integrity Protected Data Packet format.

This is fine with me.  

One suggestion:  Add a note that the old PGP sync mode is not used with
the wew packet 18.  

  Werner

From: [email-masked]
Date: Thu, 15 Jun 2000 15:28:08 -0700
To: [email-masked]
Subject: Revised MDC packet spec
Sender: [email-masked]

Based on internal discussions we would like to make a small change to
the Symmetrically Encrypted Integrity Protected Data Packet format.
We would like to include the random bytes which precede the plaintext
in the hash.  This will make the hash value less predictable and would
make an attacker's job harder.  It is also somewhat simpler conceptually
because now the material which is hashed is the same as the material
which is encrypted, except for the last 20 bytes.

Also Werner pointed out a typo in the previous draft, the 0xD0 value
should be 0xD3 to match the MDC packet CTB.  The revised draft follows.

Hal Finney
PGP.COM

============

5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 18)

   The Symmetrically Encrypted Integrity Protected Data packet contains
   data encrypted with a symmetric-key algorithm and protected against
   modification by the SHA-1 hash algorithm. When it has been decrypted,
   it will typically contain other packets (often literal data packets
   or compressed data packets).  The last such decrypted packet must be
   a Modification Detection Code packet.

   The body of this packet consists of:

     - A one-octet version number.  The only currently defined value is 1.

     - Encrypted data, the output of the selected symmetric-key cipher
       operating in Cipher Feedback mode with shift amount equal to the
       block size of the cipher (CFB-n where n is the block size).

   The symmetric cipher used MUST be specified in a Public-Key or
   Symmetric-Key Encrypted Session Key packet that precedes the
   Symmetrically Encrypted Data Packet.  In either case, the cipher
   algorithm octet is prefixed to the session key before it is
   encrypted.

   The data is encrypted in CFB mode, with a CFB shift size equal to
   the cipher's block size.  The Initial Vector (IV) is specified as
   all zeros.  Instead of using an IV, OpenPGP prefixes an octet string
   to the data before it is encrypted.  The length of the octet string
   equals the block size of the cipher in octets, plus two.  The first
   octets in the group, of length equal to the block size of the cipher,
   are random; the last two octets are each copies of their 2nd preceding
   octet.  For example, with a cipher whose block size is 128 bits or 16
   octets, the prefix data will contain 16 random octets, then two more
   octets, which are copies of the 15th and 16th octets, respectivelly.
   Unlike the Symmetrically Encrypted Data Packet, no special CFB
   resynchronization is done after encrypting this prefix data.

   The repetition of 16 bits in the random data prefixed to the message
   allows the receiver to immediately check whether the session key
   is incorrect.

   The plaintext of the data to be encrypted is passed through the SHA-1
   hash function, and the result of the hash is appended to the plaintext
   in a Modification Detection Code packet.  Specifically, the input to
   the hash function includes the prefix octet string described above
   (equal in length to the cipher block size, plus two octets), followed
   by all of the plaintext, and then also two octets of values 0xD3, 0x14.
   These represent the encoding of a Modification Detection Code packet
   tag and length field of 20 octets.

   The resulting hash value is stored in a Modification Detection Code
   packet which MUST use the two octet encoding just given to represent
   its tag and length field.  The body of the MDC packet is the 20 octet
   output of the SHA-1 hash.

   The Modification Detection Code packet is appended to the plaintext and
   encrypted along with the plaintext using the same CFB context.

   During decryption, the decrypted data should be hashed with SHA-1,
   including the prefix octet string, the plaintext itself and also the
   packet tag and length field of the Modification Detection Code packet.
   The body of the MDC packet, upon decryption, should be compared
   with the result of the SHA-1 hash.  Any difference in hash values
   is an indication that the message has been modified and SHOULD be
   reported to the user.  Likewise, the absence of an MDC packet, or
   an MDC packet in any position other than the end of the plaintext,
   also represent message modifications and SHOULD also be reported.

   Note: future designs of new versions of this packet should consider
   rollback attacks since it will be possible for an attacker to change
   the version back to 1.

5.Y Modification Detection Code Packet (Tag 19)

   The Modification Detection Code packet contains a SHA-1 hash of
   plaintext data which is used to detect message modification.  It is
   only used in the context of a Symmetrically Encrypted Integrity
   Protected Data packet.  The Modification Detection Code packet MUST
   be the last packet in the plaintext data which is encrypted in the
   Symmetrically Encrypted Integrity Protected Data packet, and MUST
   appear in no other place.

   A Modification Detection Code packet MUST have a length of 20 octets.

   The body of this packet consists of:

     - A 20-octet SHA-1 hash of the preceding plaintext data of the
       Symmetrically Encrypted Integrity Protected Data packet, not
       including prefix data but including the tag and length byte of
       the Modification Detection Code packet.

   Note that the Modification Detection Code packet MUST always use a
   new-format encoding of the packet tag, and a one-octet encoding of
   the packet length.  (These requirements are already imposed by the
   rules for tag and length encoding.)

From: [email-masked]
To: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Fri, 16 Jun 2000 06:04:16 +0900
Lines: 46
Sender: [email-masked]

From: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Thu, 15 Jun 2000 13:52:59 -0700
Message-ID: <[email-masked]>

> > > So far in this thread, two methods of encrypting headers have been 
> > > discussed: encapsulating a complete message in a message/rfc822 and 
> > > encapsulating an SMTP session in BSMTP. Both can be used for end-to-end 
> > > encryption and the first probably inter-operates quite well amongst 
> > > existing PGP/MIME or S/MIME clients.
> >
> > at this point, i'd like to see the methods mentioned/referred to in
> > some specification so i can point mail client developers at such a
> > document for the purposes of having them work on implementations that
> > will interoperate.
> 
> I don't see what any of this has to do with OpenPGP.  Modifying SMTP
> is clearly out of our scope, and message/rfc822 is already defined in
> the MIME spec.  We don't have anything to do with this, and IMO this
> discussion should be transferred elsewhere.

i think an important point is that if you look at the openpgp/mime
spec or the openpgp spec as they stand now, they don't explicitly
mention either of the methods for protecting header information of
messages.  at least i didn't notice any mention of them...perhaps i
miseed something?

last i checked, the headers are part of the message -- if one of the
goals of openpgp/mime is to protect message confidentiality, then i
think it's relevant to at least mention the aforementioned methods in
one of the openpgp specs.

how many mail clients claim pgp/mime compatibility?

  http://www.cryptorights.org/pgp-users/pgp-mail-clients.html

how many of those protect message headers?  there may be a few, but
i have yet to encouter one.

i think this is a problem that could be addressed by placing a
disucssion of the issue in an existing spec or to create a new spec
for that purpose.  it is far more likely for header protection to be
implemented that way.

we may disagree about how important header protection is, but it seems
pretty related to openpgp (at least openpgp/mime) to me.

From: [email-masked]
Date: Thu, 15 Jun 2000 13:52:59 -0700
To: [email-masked], [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Sender: [email-masked]

> > So far in this thread, two methods of encrypting headers have been 
> > discussed: encapsulating a complete message in a message/rfc822 and 
> > encapsulating an SMTP session in BSMTP. Both can be used for end-to-end 
> > encryption and the first probably inter-operates quite well amongst 
> > existing PGP/MIME or S/MIME clients.
>
> at this point, i'd like to see the methods mentioned/referred to in
> some specification so i can point mail client developers at such a
> document for the purposes of having them work on implementations that
> will interoperate.

I don't see what any of this has to do with OpenPGP.  Modifying SMTP
is clearly out of our scope, and message/rfc822 is already defined in
the MIME spec.  We don't have anything to do with this, and IMO this
discussion should be transferred elsewhere.

Hal Finney

From: [email-masked]
To: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Fri, 16 Jun 2000 04:46:36 +0900
Lines: 31
Sender: [email-masked]

From: Ian Bell <[email-masked]>
Subject: Re: confidential subject lines -> use content description field w/          pgp/mime?
Date: Fri, 9 Jun 2000 13:55:44 +0100
Message-ID: <[email-masked]>

> On Fri, 2 Jun 2000, Ian BROWN <[email-masked]> wrote:
> >This is a really important thing we need to sort out. There was extensive
> >discussion of it almost two years ago (!) but I don't know if that resulted in
> >anything in the PGP/MIME draft.
> >
> >Ned Freed's suggestion seemed to be widely agreed upon: I've attached his last
> >e-mail on the subject, but you can read the discussion in the archives at
> >www.imc.org
> 
> So far in this thread, two methods of encrypting headers have been 
> discussed: encapsulating a complete message in a message/rfc822 and 
> encapsulating an SMTP session in BSMTP. Both can be used for end-to-end 
> encryption and the first probably inter-operates quite well amongst 
> existing PGP/MIME or S/MIME clients.

at this point, i'd like to see the methods mentioned/referred to in
some specification so i can point mail client developers at such a
document for the purposes of having them work on implementations that
will interoperate.

even w/ some kind of endorsement in the form of being present in a
specification, it may take a while for header (and/or envelope)
protection to be implemented at the user-level -- i.e. there is a single
command a user can use to create such header-protected messages.

so, any plans or takers on this point?

From: [email-masked]
To: [email-masked]
Subject: Re: Is there a fully searchable Open-PGP Archive?
Date: Fri, 16 Jun 2000 04:42:43 +0900
Lines: 15
Sender: [email-masked]

From: Erron Criddle <[email-masked]>
Subject: Is there a fully searchable Open-PGP Archive?
Date: Thu, 15 Jun 2000 10:14:25 +0800
Message-ID: <[email-masked]>

> Does anyone know of a fully searchable Open-PGP archive?

i don't know of one.  i'd be glad to be informed of one.

in the mean time, i suppose the "entire archive" (perhaps it's in two
pieces now?) mentioned at:

can be downloaded and searched locally...

Date: Thu, 15 Jun 2000 10:14:25 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Is there a fully searchable Open-PGP Archive?
Sender: [email-masked]

To all,

Does anyone know of a fully searchable Open-PGP archive?

TIA.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

Date: Tue, 13 Jun 2000 14:42:07 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Open-PGP Q re DSA and keys > 1024 bit
Sender: [email-masked]

To all,

Upon reading 2440bis re DSA and a PGP key length limit of 1024 bits, I was 
wondering what the Open-PGP group recommends for signing if you use PGP 
keys > 1024 bits?

If you do use PGP Keys > 1024 bits, should you have another set of keys 
<=1024 bits for signing or is there a standard way to reduce 2048 bit PGP 
keys down to 1024 bits suitable for the DSA signature algorithm?

TIA for any info.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

From: Paul Koning <[email-masked]>
Date: Mon, 12 Jun 2000 10:38:10 -0400 (EDT)
To: [email-masked]
Cc: [email-masked]
Subject: Re: Hidden session key generation & storage
Sender: [email-masked]

>>>>> "Erron" == Erron Criddle <[email-masked]> writes:

 Erron> To all, This is only slightly related to PGP, however:

 Erron> I was wondering if there is some "standard" out there that
 Erron> defines how a session key is stored/saved/hidden after a file
 Erron> is encrypted and stored on a computer system using the same
 Erron> key. Ideally, the only thing that *should* be able to decrypt
 Erron> the file is the same computer program that generated the key.

No.

Done correctly, the only way to decrypt the file is for the human who
owns the key to supply that key.

That is the PGP way...

 Erron> You can play around with binary files, the XOR function, CRC
 Erron> checks, Hashing algorithms and a host of other "tricks" to
 Erron> "make life very difficult" for the reverse engineer, however
 Erron> is there a 100% secure way for an executable to encrypt and
 Erron> store data (to be decrypted later on by the same program)?

No, there is not.  That's why programs that offer real security DO NOT
DO THIS.

If you see a program that does do this -- i.e., can decrypt your
encrypted file without asking you for the key -- then it is by
definition insecure and should be thrown in the garbage can.

     paul

Date: Mon, 12 Jun 2000 10:47:37 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Hidden session key generation & storage
Sender: [email-masked]

To all,

This is only slightly related to PGP, however:

I was wondering if there is some "standard" out there that defines how a 
session key is stored/saved/hidden after a file is encrypted and stored on 
a computer system using the same key. Ideally, the only thing that *should* 
be able to decrypt the file is the same computer program that generated the 
key.

You can play around with binary files, the XOR function, CRC checks, 
Hashing algorithms and a host of other "tricks" to "make life very 
difficult" for the reverse engineer, however is there a 100% secure way for 
an executable to encrypt and store data (to be decrypted later on by the 
same program)?

TIA.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

From: [email-masked]
Date: Sun, 11 Jun 2000 19:26:42 -0700 (PDT)
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> > There are a bunch, although many of them are likely not in full compliance
> > with the RFC, which specifies support for certain aspects of ESMTP.
> > Remember, the entire BITNET network was implemented using BSMTP to get
> > around the 8X8 address limit of NJE. In its heyday BITNET amounted to
> > several thousand systems running on a variety of hardware and software
> > platforms.

> i was an email-only user (i.e. not a user w/ administrative knowledge)
> when i was using bitnet, so i cannot claim to have any in-depth
> knowledge.  thanks for the explanation though.

> > One implementation that is up to date is the one in PMDF, which is descended
> > from our BITNET handling code. The same code is also in SIMS.

> thank you very much for the pointers.

> > I also doubt if we would have written the specification had we not had an
> > actual implementation in hand. The BITNET experience showed that turning an
> > interactive protocol into a batch protocol has some subtle spots to it.

> in your opinion, are those subtle spots adequately and comprehensively
> covered in the rfc?

Yes they are. Indeed, this was the entire point of writing the RFC -- to
explain how this can be done and what the issues are with doing it.

> i ask because if bsmtp encapsulation is to become
> widely used (assuming here that it isn't at the moment), it seems to
> me that there may have to be a few more implementations.

Frankly, I doubt if it will ever be widely used. But writing the document
seemed to be useful given that there have been a fair number of implementations
in the past and they didn't get it right without a specification.

				Ned

From: [email-masked]
To: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Mon, 12 Jun 2000 10:40:40 +0900
Lines: 58
Sender: [email-masked]

From: Ian Bell <[email-masked]>
Subject: Re: confidential subject lines -> use content description field w/          pgp/mime?
Date: Fri, 9 Jun 2000 13:55:44 +0100
Message-ID: <[email-masked]>

> So far in this thread, two methods of encrypting headers have been 
> discussed: encapsulating a complete message in a message/rfc822 and 
> encapsulating an SMTP session in BSMTP. Both can be used for end-to-end 
> encryption and the first probably inter-operates quite well amongst 
> existing PGP/MIME or S/MIME clients.
> 
> However, encrypting message headers could also be potentially useful for 
> protecting stored messages as well, but here the message/rfc822 solution 
> is not so useful (and BSMTP not appropriate at all).

i used to think this might be a good idea, but i started thinking that
encrypting filesystems or directories where the messages are stored
(on the server end in your imap example) might be a better solution.

on the other hand, messages are sometimes stored w/in
databases...unless most databases support the notion of encrypting
records, i guess this could be problematic in that case, but may be
databases should support encryption/decryption.

> For instance, an IMAP client may want to allow its users to encrypt all 
> messages being archived on an IMAP server in order to protect the user 
> against any server security event. 

right, so you can protect against having the message contents revealed
and w/ signing against message content being tampered w/.  not to say
this idea isn't useful, but i don't know how to protect against
deletion.

> It could do this by encapsulating existing messages in a
> message/rfc822 and holding the resulting encrypted message in a
> vanilla outer message header (e.g. no subject, all addressees set to
> the user themselves etc...).
>
> However if this is done to lots of messages, the problem arises that the 
> user won't be able to distinguish between messages without the client 
> downloading and decrypting all messages (including bodies) first!

another approach:

encrypted messages a user receives could initially be decrypted on the
client end, modified to a decrypted form and placed again on the
server (whether they replace the original messages could be a policy
decision).

the server could implement confidentiality services through local
store (e.g. filesystem, directory, etc.) encryption -- a key for
decryption could be requested from the user during imap authentication
(or computed using authentication info).

all messages for a given user on the server end could then be
protected using this key.  before imap (or pop) processing occurs,
messages are decrypted.  when the processing is complete (e.g. imap
session ends), messages are encrypted.

From: [email-masked]
To: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Mon, 12 Jun 2000 10:15:49 +0900
Lines: 33
Sender: [email-masked]

From: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Thu, 08 Jun 2000 21:27:45 -0700 (PDT)
Message-ID: <[email-masked]>

...

> > p.s. does anyone know of any bsmtp processor implementations?
> 
> There are a bunch, although many of them are likely not in full compliance 
> with the RFC, which specifies support for certain aspects of ESMTP. 
> Remember, the entire BITNET network was implemented using BSMTP to get 
> around the 8X8 address limit of NJE. In its heyday BITNET amounted to 
> several thousand systems running on a variety of hardware and software 
> platforms.

i was an email-only user (i.e. not a user w/ administrative knowledge)
when i was using bitnet, so i cannot claim to have any in-depth
knowledge.  thanks for the explanation though.

> One implementation that is up to date is the one in PMDF, which is descended
> from our BITNET handling code. The same code is also in SIMS.

thank you very much for the pointers.

> I also doubt if we would have written the specification had we not had an
> actual implementation in hand. The BITNET experience showed that turning an
> interactive protocol into a batch protocol has some subtle spots to it.

in your opinion, are those subtle spots adequately and comprehensively
covered in the rfc?  i ask because if bsmtp encapsulation is to become
widely used (assuming here that it isn't at the moment), it seems to
me that there may have to be a few more implementations.

Date: Fri, 9 Jun 2000 13:55:44 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: confidential subject lines -> use content description field w/          pgp/mime?
Sender: [email-masked]

On Fri, 2 Jun 2000, Ian BROWN <[email-masked]> wrote:
>This is a really important thing we need to sort out. There was extensive
>discussion of it almost two years ago (!) but I don't know if that resulted in
>anything in the PGP/MIME draft.
>
>Ned Freed's suggestion seemed to be widely agreed upon: I've attached his last
>e-mail on the subject, but you can read the discussion in the archives at
>www.imc.org

So far in this thread, two methods of encrypting headers have been 
discussed: encapsulating a complete message in a message/rfc822 and 
encapsulating an SMTP session in BSMTP. Both can be used for end-to-end 
encryption and the first probably inter-operates quite well amongst 
existing PGP/MIME or S/MIME clients.

However, encrypting message headers could also be potentially useful for 
protecting stored messages as well, but here the message/rfc822 solution 
is not so useful (and BSMTP not appropriate at all).

For instance, an IMAP client may want to allow its users to encrypt all 
messages being archived on an IMAP server in order to protect the user 
against any server security event. It could do this by encapsulating 
existing messages in a message/rfc822 and holding the resulting 
encrypted message in a vanilla outer message header (e.g. no subject, 
all addressees set to the user themselves etc...).

However if this is done to lots of messages, the problem arises that the 
user won't be able to distinguish between messages without the client 
downloading and decrypting all messages (including bodies) first!

Two things seem to be needed to usefully support this sort of stored 
message encryption: the ability of a client to know that there are some 
replacement headers in an encrypted message and the ability of the 
client to decrypt those headers independently of the body.

This could be accomplished using an unencrypted multipart message, where 
the first part could hold the headers (text/rfc822-headers, encrypted 
using PGP/MIME or S/MIME) and the second part could hold the body (again 
encrypted). If a new type were defined (multipart/rfc822?), an IMAP 
client could recognize the top level Content-Type, download and decrypt 
the secure headers and thereafter display the decrypted header 
information to the user.

Just an idea, but without something like this, re-encrypting messages 
for storage involves either making the user enter alternative header 
details, or not securing the headers in the first place.

-- 
Ian Bell                                           T U R N P I K E  Ltd

From: [email-masked]
Date: Thu, 08 Jun 2000 21:27:45 -0700 (PDT)
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> From: [email-masked]
> Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
> Date: Wed, 07 Jun 2000 22:15:09 -0700 (PDT)
> Message-ID: <[email-masked]>

> > > for RCPT TO though, the best i've come up w/ so far is to specify an
> > > address that forwards received messages to other forwarders or to the
> > > ultimate recipient.  is it possible to do better than this?
> >
> > The RCPT TO needs to be the address of the BSMTP processor.

> hmm, so making the RCPT TO (of the outer envelope) an address that
> will forward to the address of the BSMTP processor won't work?  i
> don't understand why.  what am i missing?

Nothing; it can be any address that gets to the processor. Any amount
of aliasing or forwarding is fine. But the more actual recipients
associated with a single outer address, the better.

> p.s. does anyone know of any bsmtp processor implementations?

There are a bunch, although many of them are likely not in full compliance with
the RFC, which specifies support for certain aspects of ESMTP. Remember, the
entire BITNET network was implemented using BSMTP to get around the 8X8 address
limit of NJE. In its heyday BITNET amounted to several thousand systems running
on a variety of hardware and software platforms.

One implementation that is up to date is the one in PMDF, which is descended
from our BITNET handling code. The same code is also in SIMS.

I also doubt if we would have written the specification had we not had an
actual implementation in hand. The BITNET experience showed that turning an
interactive protocol into a batch protocol has some subtle spots to it.

				Ned

From: [email-masked]
To: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Fri, 09 Jun 2000 12:37:52 +0900
Lines: 31
Sender: [email-masked]

From: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Wed, 07 Jun 2000 22:15:09 -0700 (PDT)
Message-ID: <[email-masked]>

> > for RCPT TO though, the best i've come up w/ so far is to specify an
> > address that forwards received messages to other forwarders or to the
> > ultimate recipient.  is it possible to do better than this?
> 
> The RCPT TO needs to be the address of the BSMTP processor. 

hmm, so making the RCPT TO (of the outer envelope) an address that
will forward to the address of the BSMTP processor won't work?  i
don't understand why.  what am i missing?

> You can have a single processor for a large number of individual
> users, and if you do this, you cannot tell from the outer envelope
> what user is being sent to. Not knowing the specific user makes
> traffic analysis a heck of a lot harder.

yes, i suppose it does increase the amount of work that must be done
-- i guess that amount is related to how much use the bsmtp processor
is getting and by how many users.  so there should be incentive to use
a processor that is heavily used and by a lot of users.

i suppose one can place encrypted bsmtp objects inside of bsmtp
objects and do chaining of bsmtp processors...

thanks very much for the explanations.

p.s. does anyone know of any bsmtp processor implementations?

From: [email-masked]
Date: Thu, 08 Jun 2000 11:05:52 -0500 (CDT)
Date-warning: Date header was inserted by mta5.rcsntx.swbell.net
Subject: Shocking LOSE 10-100lbs. DESTINY
To: [email-masked]
Sender: [email-masked]

Hello From Destiny,

You will LOOSE 20-100 pounds easy!
Do to Such a high demand for Destiny, we are able
To Dramatically reduce our price for the entire System!
You will LOVE our incredible offer on this
Scientific Breakthrough in Weight Loss.
Now with a 105% Money Back Guarantee!   
LOOK! http://home.swbell.net/zainprov/destiny.htm

We hope things are going well for you.  Good luck, God Bless, and 
HAVE A GREAT DAY!

Either you are someone else subscribed to our list.  To be removed
Simply reply with a blank email.  

Thank you,

Sherry Wilson

From: [email-masked]
Date: Wed, 07 Jun 2000 22:15:09 -0700 (PDT)
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> i see that the MAIL FROM info for the container message can be made
> different from the corresponding information in the bsmtp object w/o
> having adverse affects on delivery.

> for RCPT TO though, the best i've come up w/ so far is to specify an
> address that forwards received messages to other forwarders or to the
> ultimate recipient.  is it possible to do better than this?

The RCPT TO needs to be the address of the BSMTP processor. You can have a
single processor for a large number of individual users, and if you do
this, you cannot tell from the outer envelope what user is being sent
to. Not knowing the specific user makes traffic analysis a heck of a lot
harder.

				Ned

From: [email-masked]
To: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Thu, 08 Jun 2000 13:48:40 +0900
Lines: 28
Sender: [email-masked]

From: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Tue, 06 Jun 2000 20:48:38 -0700 (PDT)
Message-ID: <[email-masked]>

...

> > assuming envelope information is protected using rfc 2442, is there a
> > recommended mechanism for actually getting the encapsulated message
> > to the receiving end?  not anonymous remailers...
> 
> Recommended, no. In practice regular SMTP is often used, in effect creating a
> variety of secure tunnel.

i see that the MAIL FROM info for the container message can be made
different from the corresponding information in the bsmtp object w/o
having adverse affects on delivery.

for RCPT TO though, the best i've come up w/ so far is to specify an
address that forwards received messages to other forwarders or to the
ultimate recipient.  is it possible to do better than this?

what am i missing?

thanks for bearing w/ me.

p.s. is this an appropriate place to discuss rfc 2442?  if not, is there
some other place?

Date: Wed, 07 Jun 2000 12:35:17 -0700
To: Dave Crocker <[email-masked]>, [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: patents?
Sender: [email-masked]

Yes, but after the RFC has a number and after there is widespread
common use of a technology goes over into the "they never enforced their
patent" area.

I mostly said what I said to shake any stealth lawyers out of the trees,
which seems to not have happened.

One can never stop scanning for submarine patents.  they pop at the
most annoying times...

At 05:24 PM 5/31/00 -0700, Dave Crocker wrote:
>At 04:46 PM 5/31/00 -0700, Rodney Thayer wrote:
>>Being as no evil lawyers from NAI or elsewhere have swooped down on this
>>list or on the IETF I'd say it's safe for now.
>>
>>At 03:05 PM 5/31/00 -0500, William H. Geiger III wrote:
>>>Probably just standard boilerplate. They are just putting you on notice
>>>that by publishing their source code they are not giving up any rights
>>>that the may hold on the code.
>
>You are both being far too optimistic.  While it is possible that you are 
>correct, it is equally possible -- and many would say more likely -- that 
>patents are, in fact, held or being prosecuted.
>
>The IETF has had some patents emerge very late in the process, so the 
>concern is not academic.
>
>d/
>
>
>=-=-=-=-=
>Dave Crocker  <[email-masked]>
>Brandenburg Consulting  <www.brandenburg.com>
>Tel: +1.408.246.8253,  Fax: +1.408.273.6464
>675 Spruce Drive,  Sunnyvale, CA 94086 USA

From: [email-masked]
Date: Tue, 06 Jun 2000 20:48:38 -0700 (PDT)
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> thanks for the clarification.

> From: [email-masked]
> Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
> Date: Tue, 06 Jun 2000 18:11:55 -0700 (PDT)
> Message-ID: <[email-masked]>

> > Two words: traffic analysis. Knowing who's getting a message is
> > often enough to tell you something even if the contents are
> > obscured.

> sure.  so the "There are many applications" statement referred to
> applications where the traffic analysis of envelope information is
> relevant.  is that a reasonable interpretation?  also, did you have
> other things in mind?

Signing the envelope also has its applications -- it prevents some forms
of envelope tampering that might otherwise be used in some sorts of
attacks.

> assuming envelope information is protected using rfc 2442, is there a
> recommended mechanism for actually getting the encapsulated message
> to the receiving end?  not anonymous remailers...

Recommended, no. In practice regular SMTP is often used, in effect creating a
variety of secure tunnel.

				Ned

From: [email-masked]
To: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Wed, 07 Jun 2000 10:39:20 +0900
Lines: 28
Sender: [email-masked]

thanks for the clarification.

From: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Tue, 06 Jun 2000 18:11:55 -0700 (PDT)
Message-ID: <[email-masked]>

> Two words: traffic analysis. Knowing who's getting a message is
> often enough to tell you something even if the contents are
> obscured.

sure.  so the "There are many applications" statement referred to
applications where the traffic analysis of envelope information is
relevant.  is that a reasonable interpretation?  also, did you have
other things in mind?

assuming envelope information is protected using rfc 2442, is there a
recommended mechanism for actually getting the encapsulated message
to the receiving end?  not anonymous remailers...

<humor>
i suppose one of these days we'll end up seeing all anonymous remailer
functionality provided via several standards documents...i think that
leaves: splitting messages up into equal size pieces (+ reassembly on
the receiving end of course), sending cover traffic, pooling message 
pieces, making message pieces traverse different paths...am i missing 
anything?  :-)
</humor>

From: [email-masked]
Date: Tue, 06 Jun 2000 18:11:55 -0700 (PDT)
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> From: [email-masked]
> Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
> Date: Sun, 04 Jun 2000 21:11:38 -0700 (PDT)
> Message-ID: <[email-masked]>

> > > does that sound about right?
> >
> > Yes, except that the protection extends to the envelope when you use BSMTP.
> > If all you want to protect is the header it is easier to just use a
> > message/rfc822 MIME encapsulation.

> so to protect the confidentiality of the Subject header:

>   sending side

>   1) create a rfc 822 message (contains Subject)
>   2) mime encapsulate the message
>   3) encrypt (and optionally sign)
>   4) send the message

>   receiving side

>   5) receive the message
>   6) decrypt (and optionally verify signature)
>   7) extract (recreate) the original message
>   8) read as usual (can see the Subject)

> right?

> if there is no better method yet, imo, it would be a good idea for
> this method of protecting headers to receive some kind of
> "endorsement" (e.g. mentioned in the openpgp/mime or some other spec
> for instance -- a separate document is may be too much, but who
> knows).

> also, i noticed the following statement in a past (septemeber 17th
> 1998) post by you in the archives:

>   There are many applications where the envelope itself is sensitive and
>   needs end-to-end protection.

> but i did not notice any concrete examples of such applications.  would you
> mind mentioning a few?

Two words: traffic analysis. Knowing who's getting a message is often enough to
tell you something even if the contents are obscured.

				Ned

From: [email-masked]
To: [email-masked]
Subject: Re: 3.6.1.3 Clarification
Date: Tue, 06 Jun 2000 18:42:11 +0900
Lines: 55
Sender: [email-masked]

From: Erron Criddle <[email-masked]>
Subject: 3.6.1.3 Clarification
Date: Tue, 06 Jun 2000 15:52:16 +0800
Message-ID: <[email-masked]>

> Just to make sure I understand before we code, two options are available 
> per instance (I am also not taking into consideration multiple instances 
> when the hash bit count is smaller than the required key length). Consider 
> the two options:
> 
> 1) A simple salt + iteration:
> 
> count=20 bytes
> salt=12 bytes
> pass phrase=12 bytes
> 
> from this, we simply do:
> 
> hash (salt + pass phrase)
> 
> where:
> 
> salt=12 bytes
> pass phrase=12 bytes

this looks correct to me.  it fulfills the "has at least one complete salt +
passphrase" requirement.

> 2) A concatenated salt + iteration:
> 
> count=40 bytes
> salt=12 bytes
> pass phrase=12 bytes
> 
> from this, we simply do:
> 
> hash(salt(0) + pp(0) + salt(1) + pp(1))
> 
> where:
> 
> salt(0)=12 bytes
> pass phrase (0)=12 bytes
> salt (1)=12 bytes
> pass phrase(1)=left 4 bytes of the 12 byte pass phrase

this looks correct to me as well.  it fulfills the "assuming at least one
complete salt + passphrase will be hashed, hash exactly count bytes"
requirement.

for reference, there was discussion of this area of the rfc recently,
and i submitted candidate alternate phrasing for this section.  you
can find that at:

  http://www.imc.org/ietf-openpgp/mail-archive/msg03156.html

Date: Tue, 06 Jun 2000 15:52:16 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: 3.6.1.3 Clarification
Sender: [email-masked]

To all,

Just to make sure I understand before we code, two options are available 
per instance (I am also not taking into consideration multiple instances 
when the hash bit count is smaller than the required key length). Consider 
the two options:

1) A simple salt + iteration:

count=20 bytes
salt=12 bytes
pass phrase=12 bytes

from this, we simply do:

hash (salt + pass phrase)

where:

salt=12 bytes
pass phrase=12 bytes

2) A concatenated salt + iteration:

count=40 bytes
salt=12 bytes
pass phrase=12 bytes

from this, we simply do:

hash(salt(0) + pp(0) + salt(1) + pp(1))

where:

salt(0)=12 bytes
pass phrase (0)=12 bytes
salt (1)=12 bytes
pass phrase(1)=left 4 bytes of the 12 byte pass phrase

Is this correct, or have I got it wrong?

TIA.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

To: [email-masked]
Cc: [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
From: Florian Weimer <[email-masked]>
Date: 05 Jun 2000 13:40:52 +0200
Lines: 53
Sender: [email-masked]

[email-masked] writes:

> The purpose of Alice's signature was to identify Bob, not to say that
> he is trustworthy.  I am the one who made that latter determination.
> Given that Alice at one time certified Bob's identity, the fact that her
> certification has expired doesn't change the fact that I still trust him.

If a certification grants access to some resource, access should
certainly be denied if the certification expires.  (Perhaps this is a
bad example, because this is quite easy to enforce during
implementation because it only affects the "server" side, not the
"client" side, where many OpenPGP implementations might coexist, while
there's only one server protecting that specific resource.)

A better example: the CA of an organization signs the public key of
one of its members, knowing the member will perhaps leave the
organization in, say, 6 months.  So the CA lets the signature expire
in 6 months.  (If he's still around at that time, his key will get
just another certificate.)  According to the CA policy, a key
certification implies the statement that the key owner is a member of
said organization.  If the signature expires and doesn't become
invalid automatically, the CA still has to issue a revocation
certificate to ensure that it's really invalid on all clients.  If the
organization has got a considerable member fluctuation, this will
result in a quickly growing certificate revocation list (CRL) which
mainly contains redundant information (the signatures are expired
anyway).

> In at least some cases, then, it might be reasonable to continue to use
> expired signatures in trust calculation.

But the user has to be notified that an expired signature was involved
at some point.  I don't it's a good idea to hide this fact.  On the
other hand, the user should be able to verify a signature which was
made some time ago, and some links in the chain of trust to the
signing key have expired since.  (Internally, we call this the
"time-travel" feature.)  If the user trusts the signer not to issue
bogus signatures, this feature is very helpful, even though OpenPGP
doesn't provide safe timestamps.

I think we can agree that the decision whether expired certificates
should be part of validity calculations or not cannot be decided
mechanically.  Since the message format specification shouldn't assume
interactive implementations, we have to make a decision here.  My
instincts say the safe alternative (i.e. expired certificates are
ignored) should be chosen.  (And our CRL wouldn't grow as fast as it
would without this additional requirement. ;)

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5

Date: Mon, 05 Jun 2000 13:57:54 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Re: Quick Triple-DES Q
Sender: [email-masked]

At 22:06 4/06/00 -0700, Jon Callas <[email-masked]> wrote:

>At 12:30 PM +0800 6/5/00, Erron Criddle wrote:
> >To all,
> >
> >Has RSA allowed a royalty/payment free use of the Triple-DES algorithm for
> >use in the OpenPGP standard?
> >
>
>No, they haven't. On the other hand, since they have utterly nothing to do
>with Triple-DES, there's no need for them to. Triple-DES is a completely
>open algorithm, which is why OpenPGP, as well as many other IETF standards,
>use it.

Oh, sorry...

I remember reading somewhere about RSA providing payment/royalty free 
access one of their algorithms and I thought it was for OpenPGP...

Must have been something else :)

As for linking Triple-DES with RSA - well, I certainly don't know where 
that came from :)

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

From: [email-masked]
To: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Mon, 05 Jun 2000 14:08:12 +0900
Lines: 47
Sender: [email-masked]

From: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Sun, 04 Jun 2000 21:11:38 -0700 (PDT)
Message-ID: <[email-masked]>

...

> > does that sound about right?
> 
> Yes, except that the protection extends to the envelope when you use BSMTP.
> If all you want to protect is the header it is easier to just use a
> message/rfc822 MIME encapsulation.

so to protect the confidentiality of the Subject header:

  sending side

  1) create a rfc 822 message (contains Subject)
  2) mime encapsulate the message
  3) encrypt (and optionally sign)
  4) send the message

  receiving side

  5) receive the message
  6) decrypt (and optionally verify signature)
  7) extract (recreate) the original message
  8) read as usual (can see the Subject)

right?

if there is no better method yet, imo, it would be a good idea for
this method of protecting headers to receive some kind of
"endorsement" (e.g. mentioned in the openpgp/mime or some other spec
for instance -- a separate document is may be too much, but who
knows).

also, i noticed the following statement in a past (septemeber 17th
1998) post by you in the archives:

  There are many applications where the envelope itself is sensitive and 
  needs end-to-end protection.

but i did not notice any concrete examples of such applications.  would you
mind mentioning a few?

http://www.imc.org/ietf-open-pgp/mail-archive/msg01941.html

Date: Sun, 4 Jun 2000 22:06:45 -0700
To: Erron Criddle <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Quick Triple-DES Q
Sender: [email-masked]

At 12:30 PM +0800 6/5/00, Erron Criddle wrote:
>To all,
>
>Has RSA allowed a royalty/payment free use of the Triple-DES algorithm for
>use in the OpenPGP standard?
>

No, they haven't. On the other hand, since they have utterly nothing to do
with Triple-DES, there's no need for them to. Triple-DES is a completely
open algorithm, which is why OpenPGP, as well as many other IETF standards,
use it.

	Jon

Date: Mon, 05 Jun 2000 12:30:59 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Quick Triple-DES Q
Sender: [email-masked]

To all,

Has RSA allowed a royalty/payment free use of the Triple-DES algorithm for 
use in the OpenPGP standard?

TIA.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

From: [email-masked]
Date: Sun, 04 Jun 2000 21:11:38 -0700 (PDT)
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> > Please note that since this discussion the BSMTP document has come out as
> > RFC 2442.

> so, if i understand the idea correctly, header protection can be had
> by having mail clients support bsmtp processing:

>   sending side

>   1) create a message
>   2) create a bsmtp object out of the message (encapsulate)
>   3) encrypt (and optionally sign)
>   4) send the message

>   receiving side

>   4) receive the message
>   5) decrypt (and optionally verify signature)
>   6) extract (recreate) the original message from the bsmtp object
>   7) read as usual

> does that sound about right?

Yes, except that the protection extends to the envelope when you use BSMTP.
If all you want to protect is the header it is easier to just use a
message/rfc822 MIME encapsulation.

				Ned

From: [email-masked]
To: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Mon, 05 Jun 2000 11:54:19 +0900
Lines: 26
Sender: [email-masked]

From: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
Date: Fri, 02 Jun 2000 19:44:26 -0700 (PDT)
Message-ID: <[email-masked]>

> Please note that since this discussion the BSMTP document has come out as
> RFC 2442.

so, if i understand the idea correctly, header protection can be had
by having mail clients support bsmtp processing:

  sending side

  1) create a message
  2) create a bsmtp object out of the message (encapsulate)
  3) encrypt (and optionally sign)
  4) send the message

  receiving side

  4) receive the message
  5) decrypt (and optionally verify signature)
  6) extract (recreate) the original message from the bsmtp object
  7) read as usual

does that sound about right?

Date: Sun, 4 Jun 2000 01:41:53 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
cc: [email-masked]
Subject: Re: Packet Numbers
Sender: [email-masked]

I think this is an excellent idea. However, a few comments:

On Sat, 3 Jun 2000, William H. Geiger III wrote:

> Hi,
> 
> I would like to propose to the list that we reserve a block of packet
> numbers for future use by NAI's PGP & GNUPG.

We'll need to propose a method for adding other implementations in the
future as well.

> This would eliminate problems of either of these vendors grabbing packet
> numbers to use for new packets for production level software (PhotoID
> packet is a good example).
> 
> I also propose that in exchange for providing these vendors with a block
> of packet numbers that they agree to document the packet formats within a
> time after using them in production level software (six months sound
> good?).

6 months sounds good. The documentation should be a supplimentary
RFC. There is no reason to have to rewrite the OpenPGP standard each time.

> Any packets that a vendor wishes to keep proprietary should stay in the
> +100 range reserved for experimental packets.

I would also propose that packet 100 be assigned to X.509 certificates,
provided NAI documents this format, and the experimental block be moved to
101 --> 110. I also propose that no implementation should use an
experimental packet in a production state (these should be for testing
only!)

- --Len.

__

L. Sassaman

System Administrator                |  "It's a nice day 
Technology Consultant               |   to start again."
icq.. 10735603                      |    
pgp.. finger://ns.quickie.net/rabbi |        --Billy Idol

From: "William H. Geiger III" <[email-masked]>
Date: Sat, 03 Jun 2000 08:56:32 -0500
To: [email-masked]
Subject: Packet Numbers
Sender: [email-masked]

Hi,

I would like to propose to the list that we reserve a block of packet
numbers for future use by NAI's PGP & GNUPG.

This would eliminate problems of either of these vendors grabbing packet
numbers to use for new packets for production level software (PhotoID
packet is a good example).

I also propose that in exchange for providing these vendors with a block
of packet numbers that they agree to document the packet formats within a
time after using them in production level software (six months sound
good?).

Any packets that a vendor wishes to keep proprietary should stay in the
+100 range reserved for experimental packets.

tks,

-- 
---------------------------------------------------------------
William H. Geiger III      http://www.openpgp.net  
Geiger Consulting    

Data Security & Cryptology Consulting
Programming, Networking, Analysis
 
PGP for OS/2:               http://www.openpgp.net/pgp.html
E-Secure:                   http://www.openpgp.net/esecure.html
---------------------------------------------------------------

Date: Fri, 02 Jun 2000 21:28:13 -0700
To: "William H. Geiger III" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: patents?
Cc: [email-masked]
Sender: [email-masked]

At 01:08 PM 6/1/00 -0500, William H. Geiger III wrote:
>In <[email-masked]>, on 05/31/00
>    at 06:24 PM, Dave Crocker <[email-masked]> said:
> >You are both being far too optimistic.  While it is possible that you are
> > correct, it is equally possible -- and many would say more likely --
> >that  patents are, in fact, held or being prosecuted.
>
>Well Dave I know several of the people in the PGP group at NAI and I don't
>think that they would allow something like this.

And, of course, I was not trying to claim that NAI has any plans or would 
take such action.  For that matter the entire history of PGP leads to the 
expectation that no such patent action would be taken.

However the question was about possibilities and implications, particularly 
with respect to the import of being late in the standards process.

That is, the important piece of information is that there is nothing that 
*forces* NAI (or any other participant) to disclose patent intent, and 
there is already some precedent (small pseudo-legal pun intended) for 
late-stage surfacing.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

From: [email-masked]
Date: Fri, 02 Jun 2000 19:44:26 -0700 (PDT)
Subject: Re: confidential subject lines -> use content description field w/ pgp/mime?
To: Ian BROWN <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> This is a really important thing we need to sort out. There was extensive
> discussion of it almost two years ago (!) but I don't know if that resulted in
> anything in the PGP/MIME draft.

> Ned Freed's suggestion seemed to be widely agreed upon: I've attached his last
> e-mail on the subject, but you can read the discussion in the archives at
> www.imc.org

Please note that since this discussion the BSMTP document has come out as
RFC 2442.

				Ned

From: [email-masked]
To: [email-masked]
Subject: Re: easy to understand openpgp book/doc?
Date: Fri, 02 Jun 2000 19:37:15 +0900
Lines: 13
Sender: [email-masked]

From: Erron Criddle <[email-masked]>
Subject: easy to understand openpgp book/doc?
Date: Fri, 02 Jun 2000 17:40:34 +0800
Message-ID: <[email-masked]>

> I was wondering if there is a book/document available that basically 
> translates the 2440/2440bis documents into an understandable format.

that would be nice to have :-)

assuming there isn't one, i'd be interested in participating in
creating something along those lines.

To: [email-masked]
cc: [email-masked]
Subject: Re: confidential subject lines -> use content description field w/  pgp/mime?
Date: Fri, 02 Jun 2000 11:28:41 +0100
From: Ian BROWN <[email-masked]>
Sender: [email-masked]

This is a really important thing we need to sort out. There was extensive 
discussion of it almost two years ago (!) but I don't know if that resulted in 
anything in the PGP/MIME draft.

Ned Freed's suggestion seemed to be widely agreed upon: I've attached his last 
e-mail on the subject, but you can read the discussion in the archives at 
www.imc.org

Ian :)
--
Date: Thu, 17 Sep 1998 11:04:15 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
To: Ian Bell <[email-masked]>
Cc: [email-masked], [email-masked]

> (Apologies if this has been done to death in the past - I can imagine
> Ned sighing about protracted discussions prior to RFC1847 - but I
> couldn't find any discussion in the archives)

> RFC2311 (SMIME) and RFC1847 (upon which PGP/MIME has been based) only
> allow MIME headers to be protected by the encryption process. Was there
> any discussion during the preparation of RFC1847 about the possibility /
> desirability / feasibility of allowing general RFC822 headers to be
> included in the encrypted part of the message?

There were extensive discussions of this. I probably have several hundred
messages archived on this topic, and there were also WG discussions and several
private meetings where the design team covered this area exhaustively.

The basic conclusion was (and is) that this dog doesn't hunt and cannot be made
to hunt. The problem is that message headers are routinely rewritten by
intervening MTAs as messages are transferred via SMTP. They are refolded,
reordered, addresses are converted from one form to another, encoded
words are added or removed, entire fields are added or deleted.

And all these activities are the rule, not the exception. And it is far more
likely to happen to fields it makes sense to sign, such as subject, to/cc/bcc,
comments, etc. than to any others.

In short, if you want to keep the transports from modifying things, you cannot
put them in the primary header. You either have to put them in the body. And
given this, MIME provides the obvious means to do this if that's what you're
after -- nested messages.

> The most obvious candidates for headers to be encrypted along with the
> MIME headers would be Subject: and Disposition-Notification-To: (the
> subject the sender may have intended to use may be too sensitive to use
> as the subject of the open message: the sender may want any MDN to be
> sent only when the message is decrypted), though cases could probably be
> made for just about any RFC822 header.

> Could (and should) any replacements for RFC2015 and RFC2311 be amended
> to allow RFC822 headers to be sent encrypted, and for the decryption
> process to swap any encrypted headers found with the corresponding
> headers in the actual message?

There is no need to do this. All you need to do is use MIME encapsulation
to put the real headers into the body of the message.

One thing that would be nice is if there was a way to say in the signature
information that the inner message is actually supposed to replace the outer
container message. (This could also be done as a parameter to message/rfc822
if need be, although there are arguments for doing it in the signature.

There is one other thing that is missing, however, and that is a means of
encapsulating the entire message including the envelope. There are many
applications where the envelope itself is sensitive and needs end-to-end
protection.

And there is a proposal on the table to deal with this:
draft-freed-bsmtp-02.txt. This defines envelope encapsulation and the semantics
that necessarily follow from doing it.

> As availability of encryption software becomes more widespread, many
> end-users may find SMIME/PGP most useful as simply a transport security
> mechanism rather than a way of securely storing messages. In any case,
> MUAs implementing PGP or S/MIME probably already allow the user to save
> the decrypted version of a message.

Sure.

> It would be good if there were an interoperable way of making the
> stored, decrypted message reflect the message the author would have
> liked to send in the first place. It would be particularly nice if the
> author could transmit the intended subject of a message when this may be
> too sensitive to put in the open message headers.

See above.

				Ned

Date: Fri, 02 Jun 2000 17:40:34 +0800
To: [email-masked]
From: Erron Criddle <[email-masked]>
Subject: easy to understand openpgp book/doc?
Sender: [email-masked]

To all,

I was wondering if there is a book/document available that basically 
translates the 2440/2440bis documents into an understandable format.

PS: I have an electronic engineering background and extensive experience 
with Internet protocols, so please, no derogatory remarks :)

TIA.

Regards

Erron Criddle
Comasp Ltd.
ACN: 089 468 682
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: +61 8 9386 9534
Mob: +414/0414 800 888

[email-masked]
http://www.comasp.com

From: [email-masked]
To: [email-masked]
Subject: confidential subject lines -> use content description field w/ pgp/mime?
Date: Fri, 02 Jun 2000 18:16:11 +0900
Lines: 71
Sender: [email-masked]

problem
-------

imo, as the number of messages using pgp (or pgp/mime) for a user
increases, the need for a mechanism for protecting the confidentiality
of subject lines (i.e. what a user sees as a subject in a mail client)
becomes greater.

important information is often stored in the subject line and not
having a meaningful subject which was specified by the author of the
message can be a serious inconvenience to users (e.g. searching,
referring to past messages in communication, etc.) -- which may likely
lead to a decision on the user's part to go ahead and place sensitive
information in the subject line.

suggestion
----------

i think it would be a good idea to address this by defining a common
specification.  afaik, there isn't one yet -- please tell me if you
know of one already.

i've asked around on a few mailing lists for ideas about this, and,
imho, the most promising one i heard was to give meaning to the
Content-Description field for a particular mime part.

the basic idea is to store the information which would normally be the
value of a Subject header as the value of a Content-Description header
which is placed in a "to-be-encrypted" text message part.

Example:

        From: Michael Elkins <[email-masked]>
        To: Michael Elkins <[email-masked]>
        Subject: encrypted in CD:
        Mime-Version: 1.0
        Content-Type: multipart/encrypted; boundary=foo;
           protocol="application/pgp-encrypted"

        --foo
        Content-Type: application/pgp-encrypted

        Version: 1

        --foo
        Content-Type: application/octet-stream

      & Content-Type: text/plain
      & Content-Description: this is the subject the user will see
      &
      & here is some message text
      &
      & :-)

        --foo--

where, as in the (open)pgp/mime specification, the ampersands indicate
which portion of the text is encrypted.

upon/after decryption, mail clients would make an effort to display
the contents of the aforementioned Content-Description field in
relevant user interface portions (e.g. title of a message window,
where subject text might be displayed in a view that listed
information about a collection of message [one message per line],
etc.).  mail clients might also make use of these Content-Description
values for the purposes of searching and filtering.

how does the basic idea sound?

p.s. this idea was originally suggested by Kazu Yamamoto
<[email-masked]>.

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 01 Jun 2000 13:08:35 -0500
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Subject: Re: patents?
Sender: [email-masked]

In <[email-masked]>, on 05/31/00 
   at 06:24 PM, Dave Crocker <[email-masked]> said:

>At 04:46 PM 5/31/00 -0700, Rodney Thayer wrote:
>>Being as no evil lawyers from NAI or elsewhere have swooped down on this
>>list or on the IETF I'd say it's safe for now.
>>
>>At 03:05 PM 5/31/00 -0500, William H. Geiger III wrote:
>>>Probably just standard boilerplate. They are just putting you on notice
>>>that by publishing their source code they are not giving up any rights
>>>that the may hold on the code.

>You are both being far too optimistic.  While it is possible that you are
> correct, it is equally possible -- and many would say more likely --
>that  patents are, in fact, held or being prosecuted.

>The IETF has had some patents emerge very late in the process, so the 
>concern is not academic.

Well Dave I know several of the people in the PGP group at NAI and I don't
think that they would allow something like this.

-- 
---------------------------------------------------------------
William H. Geiger III      http://www.openpgp.net  
Geiger Consulting    

Data Security & Cryptology Consulting
Programming, Networking, Analysis
 
PGP for OS/2:               http://www.openpgp.net/pgp.html
E-Secure:                   http://www.openpgp.net/esecure.html
---------------------------------------------------------------