Subject: OpenPGP as a standard

From: Erron Criddle <[email-masked]>
Date: Fri, 04 Aug 2000 15:49:18 +0800

To all,

I'm e-mailing regarding the possibility of OpenPGP becoming a standard.

 From discussions with people who have been involved with the standards 
process, they believe that the OpenPGP RFC has a long way to go before it 
would be accepted as a standard because the processing requirements of 
OpenPGP have been superficially regarded with respect to packet formats 
such as the calculation of the length of a packet and the combined security 
of the actual packet (ie as OpenPGP is a security standard, so NO data 
should be spooled to disk unless it is encrypted somehow).

For example, in order to calculate the length of a stream of literal data 
(before it is prepended with a one pass sig and appended with a standard 
sig, and subsequently compressed then encrypted), you have to spool the 
data to the disk if it is a very large file. In order to maintain security, 
the data SHOULD be encypted to disk, however when we want to build the 
above packet, we would then have to decrypt the data so it could be 
prepended with the 1P sig, appended with the normal sig and then compressed 
then encrypted ONCE AGAIN...etc etc

This is one example I have been quoted and I cannot say there are 
equivalent examples that "may" slow down the process of OpenPGP becoming a 
standard.

Can anyone give me any information on the status of OpenPGP in becoming a 
standard as this information would definitely be helpful for those who are 
implementing the OpenPGP RFC.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

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

---

From: [email-masked]
Date: Fri, 04 Aug 2000 17:53:51 +0900

From: Erron Criddle <[email-masked]>
Subject: OpenPGP as a standard
Date: Fri, 04 Aug 2000 15:49:18 +0800
Message-ID: <[email-masked]>

> I'm e-mailing regarding the possibility of OpenPGP becoming a standard.

i am very confused by what you mean by "becoming a standard".  would you
mind elaborating?

---

From: Werner Koch <[email-masked]>
Date: Fri, 4 Aug 2000 11:52:57 +0200

> i am very confused by what you mean by "becoming a standard".  would you

Probably he wants to say:  Moving from status Proposed Standard to
Draft Standard.

Several times we started to do the needed compatibility tests, but due
to shortages of time we haven't moved any further :-(.  Frankly it
should be pretty easy do go to Draft - There are a few implemenations
and they all interoperate;  it is just that some folks sit down and do
some actual testing.

  Werner

-- 
Werner Koch				GnuPG key:  621CC013
OpenIT GmbH                             http://www.OpenIT.de

---

From: Erron Criddle <[email-masked]>
Date: Fri, 04 Aug 2000 18:00:12 +0800

>i am very confused by what you mean by "becoming a standard".  would you

When I speak about a "standard", I am talking about OpenPGP becoming an 
IETF standard.

Look at: http://www.imc.org/smime-pgpmime.html; it states:

"The charter for the OpenPGP WG states clearly that the purpose of the 
group is to create protocols based on PGP that can become IETF standards"

I have also satisfied the quoted persons concerns regarding the length 
specifier (ie OpenPGP as a standard) as OpenPGP can handle an unspecified 
length field quite nicely and thus there is no over processing required :)

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

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

---

From: Jon Callas <[email-masked]>
Date: Fri, 4 Aug 2000 13:59:23 -0700

>should be spooled to disk unless it is encrypted somehow).

Huh? Which people?

I agree with Werner. The only things that are needed are for some people to
do some interoperability testing, and buffing and polishing on the spec.
You and others have pointed out places where it's not as clear as it should
be. Lots of us have been looking at it for so long we can't tell. All of
the discussion about things lately has been great for clarifying the spec.

>equivalent examples that "may" slow down the process of OpenPGP becoming a

You bring up an interesting issue, but it has nothing to do with OpenPGP
becoming a standard. Sorry. It's always possible that you *can* come up
with a situation where as an implementor, you have to spool data to disk
while processing it. Cope.

>implementing the OpenPGP RFC.

As has been mentioned, there has to be some interoperability testing done.
That's mainly what has to be done. Then we just need to agree whether 2440
or some later draft progresses, and then push it on the line. If it's a
later draft, then that has to become an RFC.

	Jon