Subject: Re: UserID/Auth Field in Open-PGP certs
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Date: Sat, 30 Aug 97 19:02:50 GMT

> From: Charles Breed <[email-masked]>
> wrt Identity, Open-PGP should have the ability to handle other
> types of naming conventions than just the usual RFC822. In order
> to preserve previous implementations, we should make a new packet
> type that would be the new Generic Name packet.
>
I agree.  That is, the "User" element should remain the same, an
undifferentiated byte-string.

The new "Name" element should have some version and type field in it.

But the way I'd recommend doing that is with the SPKI-SDSI "(name ...)"
construct.  Thus, the field could be used in both environments.

BTW, AS..N...1 should be avoided at all costs.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 29 Aug 97 15:31:25 -0400
To: Charles Breed <[email-masked]>
Cc: [email-masked]
Subject: Re: UserID/Auth Field in Open-PGP certs
Sender: [email-masked]

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

In <[email-masked]>, on 08/29/97 
   at 01:14 PM, Charles Breed <[email-masked]> said:

>  Hello William,

>  I launched this message on UserID naming conventions to add 'some' 
>  type of structure to the existing UserID 'packet' field. The MUA - 
>  User I/F would not be required to 'conform', but an intelligent 
>  client for corp. use, might want more structure (with some guidlines).
>  I would NOT create a new UserID Field. My initial objective here, is 
>  to measure the level of interest in adding additional convenstions.

>  If there is interest, I'll submit a more detailed explanation.

I would be intrested in seeing this advanced.

I would like to see PGP give the users options to enter different types of
UserID's with some built in format validity checking.

There should also be a UserID type field though I imagine that this would
cause compatibility problems with previous versions. There may be a way
this could be added without adversely effecting backward compatiability.
Could use the first 2 bytes of the UserID field and assign them as a type
field but limit their values to non-typeable values (values 00x-0Fx are
not likely to be found in a current userid).

I would have killed to have this implemented in the PGP key format when I
was doing my PGP integration work. Would have saved alot of jumping
through hoops for matching e-mail addresses to keys in my e-mail
applications.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Fri, 29 Aug 1997 13:16:51 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: Re: UserID/Auth Field in Open-PGP certs
Sender: [email-masked]

   Assar,

   I think we should avoid ASN.1 encoding rules at all cost, BUT if we
   are to do anything with a native X.509 cert...

   CB

At 02:55 AM 8/29/97 +0200, Assar Westerlund wrote:
>Charles Breed <[email-masked]> writes:
>> The UserID field (currently a 255 charater octet string) 
>> could handle other types, such as...
>> 
>> OpenPGPGenericName ::= CHOICE {
>> 	otherName			[0]	INSTANCE OF OTHER-NAME,
>> 	rfc822Name			[1]	255 Octet String,
>> 	dNSName		       [2]	IA5String,
>> 	x400Address	   	       [3]	ORAddress,
>> 	directoryName		       [4]	Name,
>> 	ediPartyName		       [5]	EDIPartyName,
>> 	uniformResourceIdentifier	[6]	IA5String,
>> 	iPAddress			[7]	OCTET STRING,
>> 	registeredID			[8]	OBJECT IDENTIFIER }
>
>Do you actually propose using an ASN.1-related format or did you just
>happen to write it in this format?
>
>/assar
>
>

Date: Fri, 29 Aug 1997 13:14:27 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: Re: UserID/Auth Field in Open-PGP certs
Sender: [email-masked]

  Hello William,

  I launched this message on UserID naming conventions to add 'some' 
  type of structure to the existing UserID 'packet' field. The MUA - 
  User I/F would not be required to 'conform', but an intelligent 
  client for corp. use, might want more structure (with some guidlines).
  I would NOT create a new UserID Field. My initial objective here, is 
  to measure the level of interest in adding additional convenstions.

  If there is interest, I'll submit a more detailed explanation.

CB

At 08:12 AM 8/29/97 -0400, William H. Geiger III wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>In <[email-masked]>, on 08/28/97 
>   at 04:09 PM, Charles Breed <[email-masked]> said:
>
>>Open-PGP certificates should support both...
>>	1) Identity
>>	2) Autherization
>
>>wrt Identity, Open-PGP should have the ability to handle other  types of
>>naming conventions than just the usual RFC822. In order  to preserve
>>previous implementations, we should make a new packet  type that would be
>>the new Generic Name packet.
>
>>The UserID field (currently a 255 charater octet string) 
>>could handle other types, such as...
>
>>OpenPGPGenericName ::= CHOICE {
>>	otherName			[0]	INSTANCE OF OTHER-NAME,
>>	rfc822Name			[1]	255 Octet String,
>>	dNSName		       [2]	IA5String,
>>	x400Address	   	       [3]	ORAddress,
>>	directoryName		       [4]	Name,
>>	ediPartyName		       [5]	EDIPartyName,
>>	uniformResourceIdentifier	[6]	IA5String,
>>	iPAddress			[7]	OCTET STRING,
>>	registeredID			[8]	OBJECT IDENTIFIER }
>
>>the OCTET STRING containing the IP-Address
>>"123.124.125.126" should be coded like:
>>'7B7C7D7E'H
>>  | | | |
>>123 | | | 
>>  124 | |
>>    125 |
>>       126
>
>
>Hi Charles,
>
>I am a little confused by your proposal.
>
>Are you sugessting that:
>
>A) The User Interface should support creating the various Identifiers for
>the user.
>
>B1) These Identifiers should be stored in the current UserID field or B2)
>These Identifiers should be stored in a new Identifier field in addition
>to the UserID field or B3) Theses Identifiers should be stored in a new
>Identifier field as a replacement to the UserID field. 
>
>C) Should there be a Identifier type field (0-F) or (00-FF)?
>
>
>Also should the RFC contain details on the formats of the various
>Identifiers or just pointers to other RFC's?
>
>Do you plan on any of these Identifiers to be manditory?
>
>If you could please elaborate on the use and implemntation of thes
>Identifier fields.
>
>Thanks,
>
>- -- 
>- ---------------------------------------------------------------
>William H. Geiger III  http://www.amaranth.com/~whgiii
>Geiger Consulting    Cooking With Warp 4.0
>
>Author of E-Secure - PGP Front End for MR/2 Ice
>PGP & MR/2 the only way for secure e-mail.
>OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html
            
>- ---------------------------------------------------------------
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3a
>Charset: cp850
>Comment: Registered_User_E-Secure_v1.1b1_ES000000
>
>iQCVAwUBNAbBFY9Co1n+aLhhAQEwOQQAi/ZN/r5BA7ExoVrQotrBtcJBjTCzDZau
>U+bxqTDqnKGYXbP0htuXuYyfmDs6itwm1lHDwxBMGmvCYPpm/bqwCOfb3njou6Bu
>C0CppYuvLQyYezB9BifQI56MB8AntQdDmHEWIV+FEPagGBTgDoNLLK1MdIwUl654
>W2o+kBqW19o=
>=XFbZ
>-----END PGP SIGNATURE-----
>
>
>

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 29 Aug 97 08:12:01 -0400
To: Charles Breed <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: UserID/Auth Field in Open-PGP certs
Sender: [email-masked]

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

In <[email-masked]>, on 08/28/97 
   at 04:09 PM, Charles Breed <[email-masked]> said:

>Open-PGP certificates should support both...
>	1) Identity
>	2) Autherization

>wrt Identity, Open-PGP should have the ability to handle other  types of
>naming conventions than just the usual RFC822. In order  to preserve
>previous implementations, we should make a new packet  type that would be
>the new Generic Name packet.

>The UserID field (currently a 255 charater octet string) 
>could handle other types, such as...

>OpenPGPGenericName ::= CHOICE {
>	otherName			[0]	INSTANCE OF OTHER-NAME,
>	rfc822Name			[1]	255 Octet String,
>	dNSName		       [2]	IA5String,
>	x400Address	   	       [3]	ORAddress,
>	directoryName		       [4]	Name,
>	ediPartyName		       [5]	EDIPartyName,
>	uniformResourceIdentifier	[6]	IA5String,
>	iPAddress			[7]	OCTET STRING,
>	registeredID			[8]	OBJECT IDENTIFIER }

>the OCTET STRING containing the IP-Address
>"123.124.125.126" should be coded like:
>'7B7C7D7E'H
>  | | | |
>123 | | | 
>  124 | |
>    125 |
>       126

Hi Charles,

I am a little confused by your proposal.

Are you sugessting that:

A) The User Interface should support creating the various Identifiers for
the user.

B1) These Identifiers should be stored in the current UserID field or B2)
These Identifiers should be stored in a new Identifier field in addition
to the UserID field or B3) Theses Identifiers should be stored in a new
Identifier field as a replacement to the UserID field. 

C) Should there be a Identifier type field (0-F) or (00-FF)?

Also should the RFC contain details on the formats of the various
Identifiers or just pointers to other RFC's?

Do you plan on any of these Identifiers to be manditory?

If you could please elaborate on the use and implemntation of thes
Identifier fields.

Thanks,

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

To: Charles Breed <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: UserID/Auth Field in Open-PGP certs
From: Assar Westerlund <[email-masked]>
Date: 29 Aug 1997 02:55:59 +0200
Lines: 19
Sender: [email-masked]

Charles Breed <[email-masked]> writes:
> The UserID field (currently a 255 charater octet string) 
> could handle other types, such as...
> 
> OpenPGPGenericName ::= CHOICE {
> 	otherName			[0]	INSTANCE OF OTHER-NAME,
> 	rfc822Name			[1]	255 Octet String,
> 	dNSName		       [2]	IA5String,
> 	x400Address	   	       [3]	ORAddress,
> 	directoryName		       [4]	Name,
> 	ediPartyName		       [5]	EDIPartyName,
> 	uniformResourceIdentifier	[6]	IA5String,
> 	iPAddress			[7]	OCTET STRING,
> 	registeredID			[8]	OBJECT IDENTIFIER }

Do you actually propose using an ASN.1-related format or did you just
happen to write it in this format?

/assar

Date: Thu, 28 Aug 1997 14:09:51 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: UserID/Auth Field in Open-PGP certs
Cc: [email-masked]
Sender: [email-masked]

Open-PGP certificates should support both...
	1) Identity
	2) Autherization

wrt Identity, Open-PGP should have the ability to handle other 
types of naming conventions than just the usual RFC822. In order 
to preserve previous implementations, we should make a new packet 
type that would be the new Generic Name packet.

The UserID field (currently a 255 charater octet string) 
could handle other types, such as...

OpenPGPGenericName ::= CHOICE {
	otherName			[0]	INSTANCE OF OTHER-NAME,
	rfc822Name			[1]	255 Octet String,
	dNSName		       [2]	IA5String,
	x400Address	   	       [3]	ORAddress,
	directoryName		       [4]	Name,
	ediPartyName		       [5]	EDIPartyName,
	uniformResourceIdentifier	[6]	IA5String,
	iPAddress			[7]	OCTET STRING,
	registeredID			[8]	OBJECT IDENTIFIER }

the OCTET STRING containing the IP-Address
"123.124.125.126" should be coded like:
'7B7C7D7E'H
  | | | |
123 | | | 
  124 | |
    125 |
       126

Date: Wed, 27 Aug 1997 14:27:25 +0200
To: [email-masked]
From: Hagen Wollert <[email-masked]>
Subject: Re: mandatory requirements
Sender: [email-masked]

Hello to all,

at 11:07 25.08.97 EST David Gaon <[email-masked]> wrote:

>     Allen Simpson wrote:
>     >>>1. mandatory support for strong, open and unencumbered 
>     >>>cryptographic algorithms.  Other algorithms may be optionally 
>     >>>specified, but will >>not be required for conformance.
>     
>     I disagree - There MUST NOT be any mandatory requirements for 
>     algorithms, keys, ...

I agree - but - though it sounds ridiculous - this feature
should be implied in an ordered manner by choosing 'user
agreed' in the algorithm field.

>     How about:
>     ""3. Gov and legislative policies from any country SHALL NOT be 
>     considered nor shall they be caused to impact the specifications""
>     
>     I think this what you intend!

Gov policy should not be considered in any way !  I'd even
have problems with a gov. approved key authentification as
this might lead to a 'soft take-over'.

CU,

Hagen

-- 
_____________________________________________________________________
Hagen Wollert                               [email-masked]
PGPed E-Mail welcome    -    public key available on most key-servers
2048/BBAF99CD   MD5: 11 AD A2 70 67 0A 32 CA  34 D8 F0 CE 67 8A B7 A1

Date: Tue, 26 Aug 1997 09:48:16 +0200
To: [email-masked]
From: "Anthony E. Greene" <[email-masked]>
Subject: Re: Open-PGP Charter
Sender: [email-masked]

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

At 11:07 25-08-1997 EST, David Gaon wrote:
>     Allen Simpson wrote:
>     >>>1. mandatory support for strong, open and unencumbered 
>     >>>cryptographic algorithms.  Other algorithms may be optionally 
>     >>>specified, but will >>not be required for conformance.
>     
>     I disagree - There MUST NOT be any mandatory requirements for 
>     algorithms, keys, ...
>     If two correspondents need to correspond securely, they must first 
>     establish their respective mail security capabilities (ie find out 
>     what they can receive)  through the use of other relevant mail 
>     capabilities such as Directories.
>     If they h ave compoatible capabilities, they will correspond,  if they 
>     do not, tough luck.  This is no problem for e-commerce because I 
>     expect commercial enterprises will implement a multitude of security 
>     capabilities to satisfy their cusdtomers.

I think specifying at least one algorithm and key length/format should be a 
minimum requirement for interoperability. These minimums should be met with 
freely available algorithms. If we don't specify a common denominator then 
marketing forces, not technical merit, will select a defacto common 
denominator for us.

Date: Mon, 25 Aug 97 16:49:05 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: Re:
Sender: [email-masked]

> From: "David Gaon" <[email-masked]>
>      >>>1. mandatory support for strong, open and unencumbered
>      >>>cryptographic algorithms.  Other algorithms may be optionally
>      >>>specified, but will >>not be required for conformance.
>
>      I disagree - There MUST NOT be any mandatory requirements for
>      algorithms, keys, ...

Welcome to the IETF.  We do not do things this way.

>      If they h ave compoatible capabilities, they will correspond,  if they
>      do not, tough luck.

The IETF requires _interoperable_ implementations for its Standards
Process.  That means we need to specify mandatory algorithms that all
conformant implementations will use.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Date: Mon, 25 Aug 97 12:55:24 EST
From: "David Gaon" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: PROPOSED OPEN-PGP Charter
Sender: [email-masked]

     Charles
     
     1. Great - happy to see it coming - comments below
     
     2.
     >>Charter - The group will place particular emphasis on strong 
     cryptography based on open and freely available algorithms.<<
     
     Fully concur
     
     >>Charter - 1. interoperability using cryptographic algorithms 
     >>(asymmetric/symmetric including key lengths) that are consider 
     >>strong, open and unencumbered, and 
     
     Is there any way of ensuring (or at least attempting) interoperability 
     amongst mesage security applications (e.g. PGP and RSA.  My 
     understanding is that even if the 2 applications use the same 
     algorithms, they are still not interoperable)
     
     Allen Simpson wrote:
     >>>1. mandatory support for strong, open and unencumbered 
     >>>cryptographic algorithms.  Other algorithms may be optionally 
     >>>specified, but will >>not be required for conformance.
     
     I disagree - There MUST NOT be any mandatory requirements for 
     algorithms, keys, ...
     If two correspondents need to correspond securely, they must first 
     establish their respective mail security capabilities (ie find out 
     what they can receive)  through the use of other relevant mail 
     capabilities such as Directories.
     If they h ave compoatible capabilities, they will correspond,  if they 
     do not, tough luck.  This is no problem for e-commerce because I 
     expect commercial enterprises will implement a multitude of security 
     capabilities to satisfy their cusdtomers.
     
     3.
     >>Charter - 2. limited backwards compatibility with the existing pgp 
     message
     
     ""Limited""   is good - anything more (as Allen Simpson suggested) 
     will encumber (and probably regress) the specification
     
     4.
     >>Charter - 3. Government and legislative policies from any country 
     >>SHOULD not impact the specification
     
     How about:
     ""3. Gov and legislative policies from any country SHALL NOT be 
     considered nor shall they be caused to impact the specifications""
     
     I think this what you intend!
     
     5.
     >>Charter - 5. certificate and message format
     
     Could we work towards unifying the different secure mail messsage 
     formats floating around  and making this the unified format
     
     Cheers
     
     David Gaon

Date: Mon, 25 Aug 1997 09:53:20 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: 
Sender: [email-masked]

The charter proposal looks pretty good. However, I think a more easy to
follow list of the provisions might be:

The resulting work will specify:
1. certificate and message formats that have limited backwards
compatibility with the existing PGP message format described in RFC 1991
2. a public key infrastructure and trust model
3. basic time stamping capabilities
4. mandatory minimum specifications for encryption and key exchange that
are chosen without concern for any government policies and that are
consider strong, open, and unencumbered by intellectual property rights
5. a MIME structure similar (if not identical) to RFC 2015

>Chairpersons:
>
>John W. Noerenberg, II <[email-masked]>
>Charles J. Breed <[email-masked]> co-chair

My experience has been that two chairpeople don't do a better job than one.
In this case, since Charles currently works for the company whose employees
have written the drafts we'll probably consider, I think that a single
chairman, John Noerenberg, would be better than two. (Disclaimer: both
people work for members of IMC, and John's on our board of directors.)

At 9:07 AM -0700 8/25/97, David Gaon wrote:
>     I disagree - There MUST NOT be any mandatory requirements for
>     algorithms, keys, ...
>     If two correspondents need to correspond securely, they must first
>     establish their respective mail security capabilities (ie find out
>     what they can receive)  through the use of other relevant mail
>     capabilities such as Directories.
>     If they h ave compoatible capabilities, they will correspond,  if they
>     do not, tough luck.  This is no problem for e-commerce because I
>     expect commercial enterprises will implement a multitude of security
>     capabilities to satisfy their cusdtomers.

The IESG rejected the TLS (SSL) Working Group's efforts because they didn't
include a mandatory minimum. Although they haven't said that they would do
that for all security protocols, it seems likely they will. Thus, I think
this group needs to have mandatory minimums if we want to have our work be
on standards track.

>     >>Charter - 5. certificate and message format
>
>     Could we work towards unifying the different secure mail messsage
>     formats floating around  and making this the unified format

Well, given that the other popular format (S/MIME) uses a very different
underlying format (PKCS #7), "unifying" can't happen at the same time as
any backwards compatibility with earlier PGP (or, conversely, with earlier
S/MIME). I think it is better to stay focused on the work described above.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Mon, 25 Aug 97 11:07:17 EST
From: "David Gaon" <[email-masked]>
To: [email-masked], [email-masked]
Sender: [email-masked]

     Charles
     
     1. Great - happy to see it coming - comments below
     
     2.
     >>Charter - The group will place particular emphasis on strong 
     cryptography based on open and freely available algorithms.<<
     
     Fully concur
     
     >>Charter - 1. interoperability using cryptographic algorithms 
     >>(asymmetric/symmetric including key lengths) that are consider 
     >>strong, open and unencumbered, and 
     
     Is there any way of ensuring (or at least attempting) interoperability 
     amongst mesage security applications (e.g. PGP and RSA.  My 
     understanding is that even if the 2 applications use the same 
     algorithms, they are still not interoperable)
     
     Allen Simpson wrote:
     >>>1. mandatory support for strong, open and unencumbered 
     >>>cryptographic algorithms.  Other algorithms may be optionally 
     >>>specified, but will >>not be required for conformance.
     
     I disagree - There MUST NOT be any mandatory requirements for 
     algorithms, keys, ...
     If two correspondents need to correspond securely, they must first 
     establish their respective mail security capabilities (ie find out 
     what they can receive)  through the use of other relevant mail 
     capabilities such as Directories.
     If they h ave compoatible capabilities, they will correspond,  if they 
     do not, tough luck.  This is no problem for e-commerce because I 
     expect commercial enterprises will implement a multitude of security 
     capabilities to satisfy their cusdtomers.
     
     3.
     >>Charter - 2. limited backwards compatibility with the existing pgp 
     message
     
     ""Limited""   is good - anything more (as Allen Simpson suggested) 
     will encumber (and probably regress) the specification
     
     4.
     >>Charter - 3. Government and legislative policies from any country 
     >>SHOULD not impact the specification
     
     How about:
     ""3. Gov and legislative policies from any country SHALL NOT be 
     considered nor shall they be caused to impact the specifications""
     
     I think this what you intend!
     
     5.
     >>Charter - 5. certificate and message format
     
     Could we work towards unifying the different secure mail messsage 
     formats floating around  and making this the unified format
     
     Cheers
     
     David Gaon

Date: Sun, 24 Aug 97 19:33:55 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: ASCII box diagrams
Sender: [email-masked]

> From: Jon Callas <[email-masked]>
> At 08:04 AM 8/21/97 -0400, Tony Mione wrote:
>    	4) It would be really helpful to use ascii-character box diagrams to
>    illustrate the CTB, packet length, and the assorted packet layouts (ala
> older
>    IP/TCP RFCs). They look kind of old and crufty but can clear up a great
> deal
>    of confusion when done correctly.
>
> Thanks for the suggestion, I'll look at it.
>
I suggest something like the following:

5.1 Public-Key-Encrypted Symmetric-Key

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Content    |            Length*            |    Version    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PK-Identifier ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   ...                                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PK-Algorithm  | Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Content (CTB)        0x85

   Length*              2 bytes.  Range 10 to 8191, beginning with
                        Version field.

                        Will PGP 2.6.2 generate a 2 byte length even
                        when a short (256 bit) RSA key is used???  Will
                        a 1 byte length be interpreted correctly by 2.6
                        and 5.0???  Need testing.

   Version              1 byte.  Indicates format.  Valid values are:

                          (2) identical to format (3).
                          (3) current format described.

                        The change in version from (2) to (3) prevents
                        early releases of PGP from parsing output from
                        later releases, but has no other effect.  See
                        "Version Fields" for details.

   Public-Key-Identifier (PKID)
                        8 bytes.  Aids in identifying the public key
                        used to encrypt the symmetric session key.  See
                        "Public Keys" for details.

   PK-Algorithm (PKA)   1 byte.  The public-key algorithm used.  See
                        "Public Keys" for details.  Valid values are:

                          (1) RSA

   Data                 variable.  A string of octets that is the
                        encrypted symmetric session key.

   This element is used in a message.  One or more of these elements
   precede a Symmetric-Key-Encrypted Data Element.  The recipient of the
   message finds a PK-Identifier that matches their public key, decrypts
   the symmetric session key, and then uses the session key to decrypt
   the Data Element.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Date: Sat, 23 Aug 97 14:09:23 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: content tag
Sender: [email-masked]

I had hoped that someone else would step up to my suggestion that the
content tags (nee cipher type) would be carefully listed.  Since nobody
else has done it, I've started the list.  I only have the source to
2.6.2, so here's what I have until 5.0 source is available.

Also, I see a very easy method to add SPKI-style SDSI textual
conventions to the database format.  I've proposed that on the SPKI
list, and I've included the simple addition and terminology changes that
make this possible.

hex     length   usage  element
===     ======   =====  =======
00...    none           ///
09  HT   none           SPKI VTF
0A...    none           ///
20       none           SPKI VTF
21       none           +++
22  "    none           SPKI VTF
23  #    none           SPKI VTF
24...    none           +++
28  (    none           SPKI S-expression begin
29  )    none           SPKI S-expression end
2A...    none           +++
30...    none           SPKI byte-stream format
3B...    none           +++
7B  {    none        M  SPKI base64-stream begin
7C  |    none           SPKI VTF
7D  }    none        M  SPKI base64-stream end
7E       none           +++
7F       none           ///
80       8-bit 255      +++
81      16-bit          +++
82      32-bit          +++
83      to end          +++
84       8-bit 255      +++
85      16-bit       M  Public-Key-Encrypted Symmetric-Key
86      32-bit          +++
87      to end          +++
88       8-bit 255      ??? (check rfc1991 mismatch PGP2.6.2)
89      16-bit       I  Signature
8A      32-bit          +++
8B      to end          +++
8C       8-bit 255  SI  Hash???
8D      16-bit          +++???
8E      32-bit          +++???
8F      to end          +++???
90       8-bit 255      +++
91      16-bit          +++
92      32-bit          +++
93      to end          +++
94       8-bit 255      +++
95      16-bit       X  Private-Key
96      32-bit          +++
97      to end          +++
98       8-bit 255      ??? (check rfc1991 mismatch PGP2.6.2)
99      16-bit      SI  Public-Key
9A      32-bit          +++
9B      to end          +++
9C       8-bit 255      +++
9D      16-bit          +++
9E      32-bit          +++
9F      to end          +++
A0       8-bit 255      +++
A1      16-bit          +++
A2      32-bit          +++
A3      to end       M  Compressed Data
A4       8-bit 255      ---
A5      16-bit          ---
A6      32-bit          ---
A7      to end       M  Symmetric-Key-Encrypted Data
A8       8-bit 255   ?  Version?
A9      16-bit          ---?
AA      32-bit          ---?
AB      to end       M  Obsolete-Literal?
AC       8-bit 255      +++
AD      16-bit          +++
AE      32-bit          +++
AF      to end       M  Fixed-Literal
B0       8-bit 255   A  Trust???
B1      16-bit          +++???
B2      32-bit          +++???
B3      to end          +++???
B4       8-bit 255   A  Name
B5      16-bit          ---
B6      32-bit          ---
B7      to end          ---
B8       8-bit 255      +++
B9      16-bit          +++
BA      32-bit          +++
BB      to end          +++ (?)
BC       8-bit 255      +++
BD      16-bit          +++
BE      32-bit          +++
BF      to end          +++
C0         V            +++
C1         V            Public-Key-Encrypted Symmetric-Key
C2         V            Signature
(etc.)

Usage:
        A       Assertion
        I       Issuer
        M       Message only
        S       Subject
        X       DataBase (KeyRing) only

+++:
        For future use.
        A CTB with this value is skipped,
        using the specified length.

---:
        Never generated (extension conflict).
        A CTB with this value is skipped,
        using the specified length.

///:
        MUST NOT be used.
        A CTB with this value causes a processing abort.

SPKI VTF:
        Visual Textual Format.
        A CTB with this value causes a processing abort.

to end:
        Indeterminate length runs to end of data.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Date: Sat, 23 Aug 1997 13:35:17 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
Subject: PGP specification note and suggestion
Sender: [email-masked]

>From 3.2:

The length field of an MPI describes the length starting from its most
significant non-zero bit. Thus, the MPI [00 02 01] is not formed
correctly. It should be [00 01 01].

This is required by most earlier versions of PGP (through 2.7.1) for
signatures, but not apparently for encryption or decryption.  It is not
required by 5.0.  Note that many RSA implementations return the value the
same length as the modulus, which can include leading zeros.

Also note that the above bad example would work with the earlier versions
of PGP - it simply requried the leading byte not be zero.

So, how strict is the MPI format requirement? (another "should" v.s. 
"must" debate).

---

It would help greatly if there was some minimum specification about when
data will *NOT* be split into chunks with the new CTB length scheme. 

e.g.

0xca 0x03 'P' 'G' 'P'

is easy to handle, but it would seem that

0xca 0xe0 'P' 0xe0 'G' 0xe0 'P' 0x00

is equally valid (I made this up, so may have erred in the details).

I don't want to create another state machine and I/O abstraction layer
when I don't have to, and PGP 5.0 doesn't arbitrarily do things like the
above.

What I would like is that for things like any CTB valid within a keyring,
and short (<8381 or whatever) comment type packets, that there will only
be *ONE* length entry of one or two bytes as appropriate.  If this sounds
like it makes sense, I can come up with a comprehensive list, but
generally I would only permit it for things that are inherently variable
in length (like file data contents).

---

Should the new length format be used for compressed blocks?  If the
compression algorithm will know (or can determine) the length, it is much
simpler than having to have one state machine to feed the (de)compressor,
and another to dechunk the data stream.  In fact, it is cleaner to create
a dechunk | decompress pipe, though less efficient, than the merged code -
some of the ugliest stuff I have written. 

I haven't tried generating things with these tiny length-continue segments
to see if PGP can handle them.  But for smaller machines (e.g. palmtops
and PDAs) it would be better not to have to worry about this.

Date: Sat, 23 Aug 1997 10:40:11 +1000 (EST)
From: ? the Platypus {aka David Formosa} <[email-masked]>
Reply-To: [email-masked]
To: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: PROPOSED OPEN-PGP Charter
Sender: [email-masked]

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

On Fri, 22 Aug 1997, A. Padgett Peterson P.E. Information Security wrote:

> The OPEN-PGP Specification will have provisions for;
> 1. interoperability using cryptographic algorithms (asymmetric/symmetric 
>    including key lengths) that are consider strong, open and unencumbered, 
>    and other algorithms MAY be used
> 
> This is not very good English - the word "may" removes any meaning/force.

I read the MAY as a RFC style requirement.  And as such has a (slightly)
diffrent meaning to the english one.

> 3. Government and legislative policies from any country SHOULD not impact 
> the specification
> 
> Word "SHOULD" makes it a null statement - has same effect as "MAY"

No the meaning is diffrencent.  The SHOULD suggests that it is possable
but only after we have thought about all the concequencers of this action.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep.  ex-net.scum and proud
You Say To People "Throw Off Your Chains" And They Make New Chains For
Themselves? --Terry Pratchett

Date: Fri, 22 Aug 1997 15:31:39 -0700
To: "Tony Mione" <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Comments on draft-ietf-pgp-formats00.txt
Sender: [email-masked]

At 08:04 AM 8/21/97 -0400, Tony Mione wrote:
   
   	I have a couple of questions and comments about the draft:
   
   	1) Was there a technical reason for the new packet length format.
   Limiting packets larger than 8383 bytes to powers of two seems a bit
   restrictive. Also, if that scheme is left in place, you should describe how
   padding is done and how to find the end of useful data.

I described this incompletely. I'll put the full description in the next
release. 
   
   	2) It is not clear whether this document is supersceding or
   supplementing RFC1991. The introduction suggests it is supplementing.

This document is superceding RFC1991. I plan on rewriting all parts of
RFC1991 that need updating, correcting, etc.
   
   	3) I also agree with earlier comments on the list that all currently
   supported packet types should be fully documented, not just 'some of the 
   more interesting packet types'.

I agree completely. As charming as this phrase is, it is one of the phrases
from RFC1991 that need to be drabbed-down.
   
   	4) It would be really helpful to use ascii-character box diagrams to
   illustrate the CTB, packet length, and the assorted packet layouts (ala
older
   IP/TCP RFCs). They look kind of old and crufty but can clear up a great
deal 
   of confusion when done correctly.
   
Thanks for the suggestion, I'll look at it.

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065

Date: Fri, 22 Aug 97 21:41:23 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: Re: PROPOSED OPEN-PGP Charter
Sender: [email-masked]

> From: Charles Breed <[email-masked]>
> The OPEN-PGP Specification will have provisions for;
> 1. interoperability using cryptographic algorithms
        (asymmetric/symmetric including key lengths) that are consider
        strong, open and unencumbered, and other algorithms MAY be used

This should be more than one sentence.  How about:

 1. mandatory support for strong, open and unencumbered cryptographic
    algorithms.  Other algorithms may be optionally specified, but will
    not be required for conformance.

> 2. limited backwards compatibility with the existing pgp message

I am concerned.  How about:

  2. strong backwards compatibility with the pgp 5.0, with limited
     support for earlier pgp version installed base.

> 3. Government and legislative policies from any country SHOULD not
        impact the specification

Better:
  3. Government and legislative policies MUST NOT impact the
        specification.

> 4. certificate structure and underlying trust models, as used in a
        public key infrastructure

Which public key infrastructure?

I am planning on writing up SPKI-like message formats that use the PGP
CTB space -- this weekend.

> 5. certificate and message format
> 6. basic time stamping service
> 7. MIME content types will reference RFC 2015
>
> Goals and Milestones:
>
A rather aggressive schedule.  Probably will slip.

> Chairpersons:
>
> John W. Noerenberg, II <[email-masked]>
> Charles J. Breed <[email-masked]> co-chair
>
Good luck, and thanks!

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Date: Fri, 22 Aug 97 21:35:24 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: Re: RE: PROPOSED OPEN-PGP Charter
Sender: [email-masked]

Charles, I am having problems reading your messages.  For some reason,
they don't fold in 80 columns, and in fact sometimes run beyond the 1000
characters per line (including CRLF) allowed by RFC-821.

Could you please resend the charter and your replies?

> From: Charles Breed <[email-masked]>
> X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Date: Fri, 22 Aug 1997 10:33:40 -0700
To: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
From: Charles Breed <[email-masked]>
Subject: RE: PROPOSED OPEN-PGP Charter
Cc: [email-masked]
Sender: [email-masked]

Hello Padgett,

1)
The word phrase "MAY use other algorithms", refers to those who want to include ANY cryptographic algorithm. If you want to implement "OPEN-PGP" with RSA, or some ECC asymmetric algorithm that has intellectual property rights issues, you SHOULD be able to do so. We simply would not make it a REQUIREMENT.

2)
I just answered a similar question wrt "Limited" to the list.

3)
"Government and legislative policies SHOULD not..." Take the inverse of this statement; IF the US Gov. says you MUST use a minimum of 128 key lengths...then our charter would get confusing. I think the intent is well understood, forcing a 40 key as a MUST is not a 'technically appropriate thing'

Your last statement is right on the money ! Peace

   >That is that all possible configurations need to be allowed 
   >while subsets are created for special circumstances such as France.

Cheers,
CB

At 01:08 PM 8/22/97 -0400, you wrote:
>Looks pretty good but would like some clarification:
>
>The OPEN-PGP Specification will have provisions for;
>1. interoperability using cryptographic algorithms (asymmetric/symmetric 
>   including key lengths) that are consider strong, open and unencumbered, 
>   and other algorithms MAY be used
>
>This is not very good English - the word "may" removes any meaning/force.
>
>2. limited backwards compatibility with the existing pgp message 
>
>What is meant by "limited" - read/verify signature only ? "Standard" should
>not be concerned with licening unless the intent is only to allow Public
>Domain algoritms in which case shouldn't that be in (1) ?
>
>3. Government and legislative policies from any country SHOULD not impact the specification
>
>Word "SHOULD" makes it a null statement - has same effect as "MAY"
>
>Rest is pretty much no-braners.
>
>Personal feelings are that the top level standard needs to be as open as 
>possible while allowing for subsets. That is that all possible configurations
>need to be allowed while subsets are created for special circumstances
>such as France.
>
>"What the large print giveth, the small print taketh away..."
>
>						Warmly,
>							Padgett
>
>

Date: Fri, 22 Aug 1997 13:08:48 -0400 (EDT)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: RE: PROPOSED OPEN-PGP Charter
Sender: [email-masked]

Looks pretty good but would like some clarification:

The OPEN-PGP Specification will have provisions for;
1. interoperability using cryptographic algorithms (asymmetric/symmetric 
   including key lengths) that are consider strong, open and unencumbered, 
   and other algorithms MAY be used

This is not very good English - the word "may" removes any meaning/force.

2. limited backwards compatibility with the existing pgp message 

What is meant by "limited" - read/verify signature only ? "Standard" should
not be concerned with licening unless the intent is only to allow Public
Domain algoritms in which case shouldn't that be in (1) ?

3. Government and legislative policies from any country SHOULD not impact the specification

Word "SHOULD" makes it a null statement - has same effect as "MAY"

Rest is pretty much no-braners.

Personal feelings are that the top level standard needs to be as open as 
possible while allowing for subsets. That is that all possible configurations
need to be allowed while subsets are created for special circumstances
such as France.

"What the large print giveth, the small print taketh away..."

						Warmly,
							Padgett

Date: Fri, 22 Aug 1997 09:58:15 -0700
To: Jason Dufair <[email-masked]>
From: Charles Breed <[email-masked]>
Subject: RE: PROPOSED OPEN-PGP Charter
Cc: [email-masked]
Sender: [email-masked]

Jason,

Some thought went into the phrase, "limited backwards compatibility", If you implement "open-pgp" with Diffie-Hellman Public Key Algorithm and / or use a X.509v3 cert, you'll have problems getting FULL compatibility with 2.6.x. I agree that we do not want to abandon or inhibit any of the 4 million existing users, and the spec will require the new and old versions to communicate to some usefull degree. 

CB

At 08:09 AM 8/22/97 -0500, Jason Dufair wrote:
>
>Charles  - 
>
>YES. I agree. I am concerned with the "limited backwards compatibility." I
>believe all 2.6.x message structures should be preserved. What, exactly, is
>meant by "limited backwards compatibility?"
>
>Thanks for your time.
>
>
>>2. limited backwards compatibility with the existing pgp message
>Jason Dufair
>[email-masked]
>http://www.iquest.net/~funne
>see http://www.iquest.net/~funne/jdufair.asc for PGP 2.x public key
>-Sent via the Newton MP2000-
> 

Date: Thu, 21 Aug 1997 15:23:47 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: PROPOSED OPEN-PGP Charter
Sender: [email-masked]

Please review the following proposed charter, reply "YES" if you agree or suggest modifications. thanks, CB

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

PROPOSED OPEN-PGP Charter

Description of the Working Group:
The OPEN-PGP Working Group is chartered with defining a standard method to send and receive encrypted and / or digitally signed data objects that interoperate. The group will place particular emphasis on strong cryptography based on open and freely available algorithms. The specification will define the message formats, certificate structure, required cryptographic algorithms and key lengths, and other relevant operational concerns.

The OPEN-PGP Specification will have provisions for;
1. interoperability using cryptographic algorithms (asymmetric/symmetric including key lengths) that are consider strong, open and unencumbered, and other algorithms MAY be used
2. limited backwards compatibility with the existing pgp message 
3. Government and legislative policies from any country SHOULD not impact the specification
4. certificate structure and underlying trust models, as used in a public key infrastructure
5. certificate and message format 
6. basic time stamping service
7. MIME content types will reference RFC 2015

Goals and Milestones:

October 1997: Submit first internet draft of OPEN-PGP certificate and message specification

November 1997: Submit first internet draft of OPEN-PGP PKI, Trust Model and Time Stamping

March 1998: Submit OPEN-PGP certificate and message specification for final call

April 1998: Submit OPEN-PGP PKI, Trust Model, Time Stamping for final call

May 1998: Submit OPEN-PGP certificate and message specification for Proposed Standard

July 1998: WG last call on both drafts for Proposed Standard, (including RFC 2015)

Chairpersons:

John W. Noerenberg, II <[email-masked]>  
Charles J. Breed <[email-masked]> co-chair

From: "Tony Mione" <[email-masked]>
Date: Thu, 21 Aug 1997 08:04:24 -0400
To: [email-masked]
Subject: Comments on draft-ietf-pgp-formats00.txt
Cc: [email-masked]
Sender: [email-masked]

	I have a couple of questions and comments about the draft:

	1) Was there a technical reason for the new packet length format.
Limiting packets larger than 8383 bytes to powers of two seems a bit
restrictive. Also, if that scheme is left in place, you should describe how
padding is done and how to find the end of useful data.

	2) It is not clear whether this document is supersceding or
supplementing RFC1991. The introduction suggests it is supplementing. In that
case, I would not repeat anything from RFC1991 so as not to 'blimp-out' this
document. One place you do this is in describing the CTB and packet length
formats. If this is a supplement, then simply refer the reader to RFC1991 since
this format is not generated by newer PGPs. Note that this does not apply to
elements that are still valid for the new PGP formats. For instance, you must
still define all of the packet types that are still in use with the new PGP.

	3) I also agree with earlier comments on the list that all currently
supported packet types should be fully documented, not just 'some of the more
interesting packet types'.

	4) It would be really helpful to use ascii-character box diagrams to
illustrate the CTB, packet length, and the assorted packet layouts (ala older
IP/TCP RFCs). They look kind of old and crufty but can clear up a great deal of
confusion when done correctly.

--
Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[email-masked]                 W3: http://www-ns.rutgers.edu/~mione/
PGP Fingerprint : E2 25 2C CD 28 73 3C 5B  0B 91 8A 4E 22 BA FA 9F
Editorial Advisor for Digital Systems Report   ***** Important: John 17:3 *****

Date: Wed, 13 Aug 1997 13:55:09 -0400
From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Re: extensibility & code bloat (Re: PGP cipher tags)
Sender: [email-masked]

On Mon, 11 Aug 1997, A. Padgett Peterson P.E. Information Security wrote:

> Have come to the conclusion that and ASCIIZ string is the proper answer
> with 00h indicating either none or the end of the matter. This way
> it can be 
> 1) Intelligible
> 2) If the vendor wants to use a single byte, they can (with reguistration)

And in 8.3 of the spec, part of the signature is now:

    Preferred symmetric algorithms (array of 1 byte) (Hashed)
        Symmetric algorithm numbers that indicate which algorithms
        the key holder prefers to use.  This is an ordered list of
        bytes with the most preferred listed first.  It should be
        assumed that only algorithms listed are supported by the
        -------------------------------------------------

        recipient's software.  Algorithm numbers are provided below.
        If this subpacket is not included, IDEA is assumed.  This is
        found on a self-signature.

This could get really fun.  If I don't include IDEA and/or CAST
explicitly, but only have "\377Blowfish\0", no one could send me a message
even if the software did support the other algorithms.

And how do I specify I prefer RIPEMD160 hashes in El Gamal signatures?

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 13 Aug 1997 09:51:48 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: BOF at IETF
Sender: [email-masked]

In a fit of uncontrolled volunteerism I managed to offer to write up 
the minutes to the BOF (meeting) at the IETF.  I've got that 
partially complete and will be posting it shortly.  I would 
appreciate any feedback if I failed to record something or made any 
mis-statements.

-- Rodney Thayer Sable Technology +1 617 332 7292
   <http://www.shore.net/~sable/info/contact_info.html> --

Date: Tue, 12 Aug 1997 14:41:45 -0400
From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Re: extensibility & code bloat (Re: PGP cipher tags)
Sender: [email-masked]

In pgp 5.0:

There are 2 Public Key Algorithms, 3 Conventional Algorithms, 3 Hashes,
and 3 signature algorithms (with El Gamal enabled - it does work).

54 ways to send your encrypted signed message.  Playing with a full deck
plus two jokers?

pgpv handles all these variants properly (the just scanned in version),
but how do I get pgpe (for any platform) to generate all of them?

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Tue, 12 Aug 1997 09:41 -0500 (EST)
Subject: Re: algorithm ID encodings & terminol.
From: Jason Dufair <[email-masked]>
To: allas Jon <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Adam Back <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

------------------
>You obviously were never an embedded systems programmer :).
>
>After you expand everything to need a 256K buffer, you can have the fun of
>coding PGP5 for the USR Palm Pilot :).
------------------
I am indeed porting PGP 5 to the Newton MessagePad. While it is less
restrictive than the Pilot, I would not classify it as "fun". :-)

-----
Jason Dufair
[email-masked]
http://www.iquest.net/~funne
see http://www.iquest.net/~funne/jdufair.asc for PGP 2.x public key
-Sent via the Newton MP2000-

From: Felix Lee <[email-masked]>
Subject: Re: PGP Message Exchange Formats Internet Draft 
To: Hagen Wollert <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Mon, 11 Aug 1997 14:51:38 -0700
Sender: [email-masked]

> I'm afraid for the moment we are at a point here it is to decide whether to
> imply anything into one comprehensive format (like Tiff) or have many
> formats parallel formats like a set of (Tiff, Gif, JPEG, TGA, BMP, PCX,
> etc.) with a whole lot of compatbility problems in the future.

just want to point out: comprehensive format is not
sufficient to solve compatibility problems.  Tiff is a case
in point.
--

Date: Mon, 11 Aug 1997 10:57:29 -0400
From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Re: PGP Message Exchange Formats Internet Draft
Sender: [email-masked]

On Mon, 11 Aug 1997 [email-masked] wrote:

> Speaking of which, since DSA has only 160 bytes, and does not use the ASN1

OOPS----------------------------------------bits------------------------DER?

> prefix string that the RSA signatures use, are these going to be dropped?

> If/when you allow El Gamal signatures, will they be the lower 20 bytes
> with that PKCS padding and will they use the ASN1 strings, and what are
> they for RIPE-MD-160 and SHA1 - I think they are blank in the source.

Ah, those do use the PKCS padding and the DER prefixes.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 11 Aug 1997 10:52:04 -0400
From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Re: PGP Message Exchange Formats Internet Draft
Sender: [email-masked]

On Mon, 11 Aug 1997 [email-masked] wrote:

> if ( hash_alg != SHA1_hash )
> 	return (bad_alg)

Now that I have downloaded the source:

pgpDSAKey.c, around line 175, in dsaVerify:

        if (h->type != PGP_HASH_SHA)
                return 0;       /* No match for sure! */

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 11 Aug 1997 10:28:00 +0100
From: Robert Guerra <[email-masked]>
To: "[email-masked]" <[email-masked]>, RProcess <[email-masked]>
Subject: [Fwd: [PGP-USERS] PGP 5.0i is now available ... !]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------7FBEC43152A0910EED1D2F1D
Content-Type: text/plain; charset=us-ascii
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

In case this bit of important news yet hasn't made it this way....

--------------7FBEC43152A0910EED1D2F1D
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Mailing-List: contact [email-masked]; run by ezmlm
Reply-To: [email-masked]
Date: Mon, 11 Aug 1997 15:17:41 +0200
To: [email-masked]
From: "F. A. Friedrichs" <[email-masked]>
Subject: [PGP-USERS] PGP 5.0i is now available ... !

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

Hello!

The international version of PGP 5.0i is now available at http://www.pgpi.co=
m

...

>>>>
[...]

     PGP 5.0i released!

The platform independent volumes of the PGP 5.0 source code books have now=
=20
been
scanned in and proof-read. This includes the whole encryption library with=
=20
the new
algorithms, key formats and keyserver support. A Unix command line version o=
f

PGP
5.0i is available for download now. The Windows and Macintosh versions will=
=20
take a
few more weeks to finalize, because the binary files (which are radix64=20
encoded) have
shown to be very difficult to proof-read. You can read more about the=20
scanning project
here.

[...]

<<<<

Greetings,
Frank ...

__________________________________________________________________
Frank A. Friedrichs <mailto:[email-masked]> http://faf.home.pages.de/
2048bits-RSA-PGPKeyID:0xCB62BDA1  4096bits-RSA-PGPKeyID:0x65DDC189
2048: mailto:[email-masked]?Subject=3DGET%200xCB62BDA1
4096: mailto:[email-masked]?Subject=3DGET%200x65DDC189
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF

--------------7FBEC43152A0910EED1D2F1D--

Date: Mon, 11 Aug 1997 10:01:39 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: Adam Shostack <[email-masked]>, Jonathan Wienke <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: PGP Message Exchange Formats Internet Draft
Sender: [email-masked]

On Fri, 8 Aug 1997, Jon Callas wrote:

> There's already a constant for RIPE-MD/160. It may have gotten slipped from
> that draft. There will be another draft once we're back from Europe.
> 
> 	Jon

Yes, and if anyone bothered to buy the source, they would find out the
number is 3.

They also might notice that the DSAVerify routine has a line of the form

if ( hash_alg != SHA1_hash )
	return (bad_alg)

So anyone actually using RIPE-MD/160 for signatures will have them shown
as bad although they are mathematically correct (also applies to MD5).

Speaking of which, since DSA has only 160 bytes, and does not use the ASN1
prefix string that the RSA signatures use, are these going to be dropped?

If/when you allow El Gamal signatures, will they be the lower 20 bytes
with that PKCS padding and will they use the ASN1 strings, and what are
they for RIPE-MD-160 and SHA1 - I think they are blank in the source.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 11 Aug 1997 09:55:18 -0400
From: [email-masked]
To: [email-masked]
cc: Adam Back <[email-masked]>, [email-masked], [email-masked]
Subject: Re: extensibility & code bloat (Re: PGP cipher tags)
Sender: [email-masked]

On Sat, 9 Aug 1997 [email-masked] wrote:

> Have people considered seperating the mode from cipher used?  Each cipher 
> would have a small number of functions and constants to define 
> (functions: expand_key and encrypt_block (which would also decrypt 
> block), and constants: key_length, expanded_key_length, and 
> block_length).  The next layer would be multi-encryption (for instance, 
> 3-EDE).  The layer above that would be mode (CBC, code book, etc).  The 
> encoding would then be something like:
>     CBC-3EDE-DES
> With the three parts each going to the three layers.
> 
> This would keep code bloat down (among other things, like making 
> experimentation easier).  There would be a slight cost in performance (a 
> couple of extra function calls, and the dropping of some possible 
> optimizations- like dropping the initial/final permutations between 
> rounds of 3DES).
> 
> Thoughts?

PGP 5.0 has copied the CFB with IV in the first 8 encrypted bytes with two
check bytes from IDEA in 2.6.3 to DES and CAST.  It seems to be "baked
in".  So before we go ahead and propose layering, it might be nice to work
out these little details.  If CFB is going to be a quirky CFB, will
"plain" CFB be another mode?  And CBC now exists for 3DES, CAST, and IDEA
in other implementations.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 11 Aug 1997 15:52:41 +0200
To: [email-masked]
From: Hagen Wollert <[email-masked]>
Subject: Re: PGP Message Exchange Formats Internet Draft 
Cc: [email-masked]
Sender: [email-masked]

Hello to all,

at 10:12 11.08.1997 +0200 Assar wrote:

>[..] let's focus on
>the essential point here, and that is compatibility. There is no point in
>sending a message out into the world that the spooks can't read, when the
>recipient can't read it either because he doesn't happen to have PGP
>5.123.2 (or whatever) on his machine.

I'd like to refer to te Tiff-format again: There surely might be
comprehensive readers being able to read&write in many formats and I think
the old standard  (RSA/IDEA/MD5) and a set coping with the actual future
standard (whatever it might be) should be read by all. Therefore slimmed
versions might run on handheld systems with acceptable performance whereas
versions reading and writing any known format will more memory or computing
power when using longer keys.

>The choice of algorithm is largely a
>matter of opinion and politics, and everyone has his own personal favorite.
>If we *really* open this up, then it won't be long before there are an
>infinite number of possibilities. (Perhaps we'll even see Rot13 in there -
>it's fast and someone out there somewhere loves it.)

:-)

I'm afraid for the moment we are at a point here it is to decide whether to
imply anything into one comprehensive format (like Tiff) or have many
formats parallel formats like a set of (Tiff, Gif, JPEG, TGA, BMP, PCX,
etc.) with a whole lot of compatbility problems in the future.

IMHO the first option should be given the choice.

>Perhaps it is possible to come up with some form of 'plugin' architecture,
>allowing the enthusiasts to think up any number of options for themselves,
>but keeping the core clean and compatible.

Yes, a plug-in-architecture might be the optimum. Especially there
definitely will be future needs similar to those occurred today: DES is no
longer considered secure and there definitely are problems with MD5.
 
Who dares to estimate that factorizing large numbers won't be more easy
within 10 years thus endangering RSA ?  With an universal standard one would
just have to change from RSA to anything else (Diffie-Hellman, El-Gamal or
whatever yet to be developed) and still will provide downward compatibility.

Read you,

Hagen

-- 
_____________________________________________________________________
Hagen Wollert                               [email-masked]
PGPed E-Mail welcome    -    public key available on most key-servers
2048/BBAF99CD   MD5: 11 AD A2 70 67 0A 32 CA  34 D8 F0 CE 67 8A B7 A1

Date: Mon, 11 Aug 1997 09:48:28 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: Adam Back <[email-masked]>, [email-masked], [email-masked]
Subject: Re: algorithm ID encodings & terminology (was Re: PGP Message Exchange Formats Internet Draft)
Sender: [email-masked]

On Fri, 8 Aug 1997, Jon Callas wrote:

> At 5:16 AM -0700 8/8/97, Adam Back said:
> 
>    Why are PGP so keen to hand huffman encode everything?
> 
> I concur completely. I once got so fed up with this habit that I tromped
> around the office singing, "Every bit is sacred / Every bit is great / When
> a bit is wasted / Phil gets quite irate."
> 
> Consider this to be one of the prime things to correct. Personally, I think
> that numbers should never (well, hardly ever) be smaller than 32 bits.
> 
> 	Jon

You obviously were never an embedded systems programmer :).

After you expand everything to need a 256K buffer, you can have the fun of
coding PGP5 for the USR Palm Pilot :).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 11 Aug 1997 8:38:07 -0400 (EDT)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: extensibility & code bloat (Re: PGP cipher tags)
Sender: [email-masked]

Have come to the conclusion that and ASCIIZ string is the proper answer
with 00h indicating either none or the end of the matter. This way
it can be 
1) Intelligible
2) If the vendor wants to use a single byte, they can (with reguistration)

Since virtually all complilers include routines to handle ASCIIZ strings,
handling would be easy.

Wasn't that easy.
					Warmly,
						Padgett

Date: Mon, 11 Aug 1997 10:41:39 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: comments on message exchange draft [not encodings!]
Sender: [email-masked]

I have some comments -- 

-- I assume this iteration of this draft is intended to document current
practice so I assume we're not opening up the body for massive changes,
regardless of their brilliance.

-- this document seems to duplicate some of the information in
Stallings/etc.' existing PGP RFC.  I don't see why.

-- the name contents should be more clearly spelled out.  For example the
fact you can do 'comment' [with viacrypt but not with pgp 5 :-(] should be
more clearly described.

-- there should be more detailed CRC reference information.  If you can
suck in the Base 64 prose for the n-th time in the IETF draft world, you
can suck in the CRC information.

-- Rodney Thayer Sable Technology +1 617 332 7292
   <http://www.shore.net/~sable/info/contact_info.html> --

Date: Mon, 11 Aug 1997 10:12:49 +0200
To: Johnny Eriksson <[email-masked]>
From: Ian Sparkes <[email-masked]>
Subject: Re: PGP Message Exchange Formats Internet Draft 
Cc: [email-masked]
Sender: [email-masked]

At 12:59 08.08.97 DST, you wrote:
>Assar wrote:
>
>> Jonathan Wienke <[email-masked]> writes:
>> > Instead of having a 1-byte cipher identifier, I would like to see a 4
byte
>> > text identifier for ciphers and hashes, so IDEA could be designated by
>> > "IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it
much
>> > easier for PGP to support numerous algorithms, and multiple encryption.
>> 
>> Do you really see a new for more than 256 algoritms?
>
>No, but...  256 is a rather low value for infinity, no matter what you
>are using it for.  2^32 is a low value for the max number of IP addresses,
>but it looked more than enough a number of years ago.
>
>We might not see a need for more than 256 types right now, but it's still
>stupid to restrict things.  And having a 4-byte menmonic name is cute.

I'm happy to see 1 byte, 4 bytes, any length you want, but let's focus on
the essential point here, and that is compatibility. There is no point in
sending a message out into the world that the spooks can't read, when the
recipient can't read it either because he doesn't happen to have PGP
5.123.2 (or whatever) on his machine. The choice of algorithm is largely a
matter of opinion and politics, and everyone has his own personal favorite.
If we *really* open this up, then it won't be long before there are an
infinite number of possibilities. (Perhaps we'll even see Rot13 in there -
it's fast and someone out there somewhere loves it.)

Perhaps it is possible to come up with some form of 'plugin' architecture,
allowing the enthusiasts to think up any number of options for themselves,
but keeping the core clean and compatible.

>
>> /assar
>
>--Johnny
>
>

Date: Sun, 10 Aug 1997 22:35:24 +0000
From: Mark Grant <[email-masked]>
Reply-To: Mark Grant <[email-masked]>
Subject: Re: algorithm ID encodings & terminology (was Re: PGP Message Exchange Formats Internet Draft)
To: Adam Back <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Fri, 8 Aug 1997, Adam Back wrote:

> Why are PGP so keen to hand huffman encode everything?

Presumably to increase security; longer identifiers give an attacker more
known -- or easily guessed -- plaintext. While I consider a brute-force
attack on PGP infeasible for a long time I'm not sure that we should be
giving away more known plaintext than we need to. 

(Excuse my ignorance if we're not talking about the same identifiers; I
haven't read the PGP format documentation for some time). 

	Mark

|-----------------------------------------------------------------------|
|Mark Grant M.A., U.L.C.	  	       EMAIL: [email-masked]  |
|WWW: http://www.unicorn.com/	  	       MAILBOT: [email-masked]	|
|-----------------------------------------------------------------------|

Date: Sat, 9 Aug 97 20:13:50 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: purpose: evolution or revolution
Sender: [email-masked]

Gentlefolk, it appears to me that there are rather different goals for
some of the participants.

Some only desire a good documentation of what is already there.

Many are interested in making minor modifications to clean it up a bit.

Still others seem ready to completely redo and expand the PGP format,
using 16 bit fields where there were 8 bits, or variable length, or even
entire grammars.

When the BoF is held, please discuss this issue.

====

For myself, put me in the middle -- minor modifications, every bit is
sacred, and past and present interoperability reigns supreme.

Let SPKI handle variable length everything.  A different effort.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Date: Sat, 9 Aug 1997 18:19:00 -0500 (CDT)
From: [email-masked]
To: Adam Back <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: extensibility & code bloat (Re: PGP cipher tags)
Sender: [email-masked]

Have people considered seperating the mode from cipher used?  Each cipher 
would have a small number of functions and constants to define 
(functions: expand_key and encrypt_block (which would also decrypt 
block), and constants: key_length, expanded_key_length, and 
block_length).  The next layer would be multi-encryption (for instance, 
3-EDE).  The layer above that would be mode (CBC, code book, etc).  The 
encoding would then be something like:
    CBC-3EDE-DES
With the three parts each going to the three layers.

This would keep code bloat down (among other things, like making 
experimentation easier).  There would be a slight cost in performance (a 
couple of extra function calls, and the dropping of some possible 
optimizations- like dropping the initial/final permutations between 
rounds of 3DES).

Thoughts?

Brian

Any resemblance of these opinions to the opinions of Brian Hurt, Bit 3 
Computer Corporation, or any individual living or dead is purely 
coincidental.

Date: Sat, 9 Aug 1997 13:20:34 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: extensibility & code bloat (Re: PGP cipher tags)
Sender: [email-masked]

Peter Gutmann <[email-masked]> writes:
> Death rays from Mars made Adam Back <[email-masked]> write:
> >I was kind of toying with the idea of creating a human readable formal 
> >grammar which describes algorithm combinations.  
>  
> This gets ugly real quick.  I thought of doing this for cryptlib, something 
> like: 
>  
>   cryptAlgorithm = 3des { mode = cbc, padding = PKCS#5, noKeys = 2 }
>   cryptAlgorithm = safer { mode = cfb, keysize = 128, useSaferSK = TRUE }
>            
> (and even wrote most of a parser for it) but dropped it for a number of 
> reasons:
>  
> 1. The code to parse this starts to get scary, because when a (say)
> dlopen()'d module registers a new algorithm it also has to register
> a grammar to allow its config settings to be parsed.  Some of the
> parsing code may have to reside in the crypto module, because the
> general parser won't be aware of every conceivable type of config
> option and setting in advance.

Yup.  Interesting that you gave it a go also.  I was thinking of using
perl... the eval function plus a bit of hacking around would mean that
the extension language was almost perl code, and you'd pass it through
various filtering rules to make good perl code before evaling it.

As you say you'd have the extensions signed by people, and users could
base their trust on that in a distributed fashion.  If PRZ signs
El-Gamal and CAST well then a lot of people would use that
recommendation.  But if I'm paranoid, and the random number generator
is good enough to not become the weak point, I can request 

	R = RANDOM( sizeof(M) ), C = 5DES(M) xor 3IDEA(M XOR R)

(With 2x expansion of message size -- the simple way to have something
as good as the better of two ciphers -- now if someone finds a new
type of attack which means 3IDEA turns out to be naff, I'm OK so long
as 5DES doesn't fall.  All presuming the RANDOM function is good
enough).

I also consider that it would be interesting for the sender to be able
to request replies using the senders chosen cipher set.

> 3. Virtually noone will ever use this capability.  I know from
> feedback from cryptlib users that virtually noone uses the InitEx()
> functions (which allow you to specify special-case parameters), and
> I can't see this as being any different from PGP.

Sure.  It's not a main stream issue -- PGP isn't going to get involved
in all the extra complexity because it's not commercially justifiable.
Was just pleading the case to make it flexible so that there was room
for expasion in un-predicted directions.

Adam

Date: Sat, 09 Aug 1997 07:59:08 -0700
To: [email-masked], [email-masked]
From: Jonathan Wienke <[email-masked]>
Subject: Re: extensibility & code bloat (Re: PGP cipher tags)
Sender: [email-masked]

--=====_Eudora-PGP-Plugin19044==_
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:47 PM 8/9/97, Peter Gutmann wrote:
>
>Death rays from Mars made Adam Back <[email-masked]> write:
> 
>>>Assar Westerlund <[email-masked]> writes:
>>> - If there's a need for more than 256 algorithms, how should these be
>>> coded?  In binary or in ascii?  Fixed length or variable length?
>>ASCII, variable length.
>>
>>I was kind of toying with the idea of creating a human readable formal 
>>grammar which describes algorithm combinations.  Might save multiple
entries 
>>for DES (DES CBC, DES CFB, DES OFB, 3DES-EDE, etc.,etc), and would allow
you 
>>to "implement" a chosen mode just by specifying what mode you wanted DES,
and 
>>how to combine that to mutliple key DES. Anyone for outer-CBC 5DES?
> 
>This gets ugly real quick.  I thought of doing this for cryptlib, something 
>like: 
> 
>  cryptAlgorithm = 3des { mode = cbc, padding = PKCS#5, noKeys = 2 }
>  cryptAlgorithm = safer { mode = cfb, keysize = 128, useSaferSK = TRUE }
>           
>(and even wrote most of a parser for it) but dropped it for a number of 
>reasons:
> 
>1. The code to parse this starts to get scary, because when a (say)
dlopen()'d 
>module registers a new algorithm it also has to register a grammar to allow 
>its config settings to be parsed.  Some of the parsing code may have to
reside 
>in the crypto module, because the general parser won't be aware of every 
>conceivable type of config option and setting in advance.

On the other hand, if you have an ASCII string descriptor for each
algorithm permutation (such as "3DES-3Key-CFB") and a set of plug-ins that
each handle a set of permutations, (one does "RC4-128", "RC4-64", and
"RC4-40", another does "IDEA-PGP" and "IDEA-CFB", another does "FEAL-NSA",
etc.) then writing code that invokes the correct plug-in and passes it the
descriptor string and other data is fairly straightforward.

Given the average public key size seems to be about 1024 bits (128
bytes/octets), there is certainly room for a string descriptor for the
encryption algorithm/mode, the session key, the signature algorithm/mode,
and the ID/fingerprint of the signature key in the public key encrypted
portion of the message header.

For example:
 9 bytes: "IDEA-PGP" (length + 8 data bytes)
17 bytes: IDEA session key (length + 16 data bytes)
 8 bytes: "ElGamal" (length + 7 data bytes)
21 bytes: signature key fingerprint (length + 20 data bytes)
55 bytes total.

This would still leave 73 bytes for random padding or other purposes.

Jonathan Wienke

What part of "the right of the people to keep and bear Arms, shall not be
infringed" is too hard to understand? (From 2nd Amendment, U.S. Constitution)

PGP 2.6.2 RSA Key Fingerprint: 7484 2FB7 7588 ACD1  3A8F 778A 7407 2928
DSS/D-H Key Fingerprint: 3312 6597 8258 9A9E D9FA  4878 C245 D245 EAA7 0DCC
Public keys available at pgpkeys.mit.edu. PGP encrypted e-mail preferred.

US/Canadian Windows 95/NT or Mac users:
Get Eudora Light + PGP 5.0 for free at http://www.eudora.com/eudoralight/
Get PGP 5.0 for free at http://bs.mit.edu:8001/pgp-form.html
Commercial version of PGP 5.0 and related products at http://www.pgp.com
Eudora + PGP = Free, Convenient Communication Privacy

Go postal! Write your mommy a letter!
--=====_Eudora-PGP-Plugin19044==_
Content-Type: application/pgp-signature

--=====_Eudora-PGP-Plugin19044==_--

Date: Fri, 8 Aug 1997 06:45:08 -0700
To: Adam Shostack <[email-masked]>, [email-masked] (Jonathan Wienke)
From: Jon Callas <[email-masked]>
Subject: Re: PGP Message Exchange Formats Internet Draft
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

There's already a constant for RIPE-MD/160. It may have gotten slipped from
that draft. There will be another draft once we're back from Europe.

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065

Date: Fri, 8 Aug 1997 06:56:14 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: algorithm ID encodings & terminology (was Re: PGP Message Exchange Formats Internet Draft)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 5:16 AM -0700 8/8/97, Adam Back said:

   Why are PGP so keen to hand huffman encode everything?

I concur completely. I once got so fed up with this habit that I tromped
around the office singing, "Every bit is sacred / Every bit is great / When
a bit is wasted / Phil gets quite irate."

Consider this to be one of the prime things to correct. Personally, I think
that numbers should never (well, hardly ever) be smaller than 32 bits.

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: extensibility & code bloat (Re: PGP cipher tags)
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Date: Sat, 9 Aug 1997 18:47:35 (NZST)
Sender: [email-masked]

Death rays from Mars made Adam Back <[email-masked]> write:
 
>>Assar Westerlund <[email-masked]> writes:
>> - If there's a need for more than 256 algorithms, how should these be
>> coded?  In binary or in ascii?  Fixed length or variable length?
>ASCII, variable length.
>
>I was kind of toying with the idea of creating a human readable formal 
>grammar which describes algorithm combinations.  Might save multiple entries 
>for DES (DES CBC, DES CFB, DES OFB, 3DES-EDE, etc.,etc), and would allow you 
>to "implement" a chosen mode just by specifying what mode you wanted DES, and 
>how to combine that to mutliple key DES. Anyone for outer-CBC 5DES?
 
This gets ugly real quick.  I thought of doing this for cryptlib, something 
like: 
 
  cryptAlgorithm = 3des { mode = cbc, padding = PKCS#5, noKeys = 2 }
  cryptAlgorithm = safer { mode = cfb, keysize = 128, useSaferSK = TRUE }
           
(and even wrote most of a parser for it) but dropped it for a number of 
reasons:
 
1. The code to parse this starts to get scary, because when a (say) dlopen()'d 
module registers a new algorithm it also has to register a grammar to allow 
its config settings to be parsed.  Some of the parsing code may have to reside 
in the crypto module, because the general parser won't be aware of every 
conceivable type of config option and setting in advance.
 
2. This doesn't work well under Windows where config options are held in the 
registry and might be administered by third-party software (for example a 
company might want to have a centrally-enforced policy of "No RSA until 2000", 
which would be controlled by the administrator setting the signAlgorithm to 
ElGamal on all the machines in the domain).  It's easy enough to do this if 
it's an integer, you look up what you want in a table and set the 
"signAlgorithm" key to 17 (or whatever ElGamal is), but if you have to build 
up a huge long text string it gets complicated.  It gets even more complex if 
the policy is "We allow anything nonpatented", because a check like "( id == 
17 || id == 18 )" is a lot easier to perform than one involving 
arbitrarily-formatted strings which can contain God knows what.
 
3. Virtually noone will ever use this capability.  I know from feedback from 
cryptlib users that virtually noone uses the InitEx() functions (which allow 
you to specify special-case parameters), and I can't see this as being any 
different from PGP.  
 
What you'd be doing is adding a lot of extra complications with little overall 
gain (in fact the added complexity is probably going to cause more problems 
than it's worth, not only because of the overhead in managing it but because 
allowing people to specify 7DES/CFB-47 will almost guarantee that anything 
they produce can't be decrypted by anyone else on earth).
 
Peter.

Date: Fri, 8 Aug 1997 20:21:41 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: extensibility & code bloat (Re: PGP cipher tags)
Sender: [email-masked]

Assar Westerlund <[email-masked]> writes:
> - Do we really need more than 256 algorithms _in PGP_?
> 
> [...]
> 6.2 Symmetric Key Algorithms
> 
> 0	-	Plaintext
> 1	-	IDEA
> 2	-	Triple-DES (DES-EDE, 168 bit key)
                            ^^^^^^^^^^^^^^^^^^^^ 

I think this answers your question: yes.  There are lots of modes, key
sizes, etc.  And a variable length algorithm description string costs
almost nothing and offers ultimate flexibility, so why not do it.

> - If there's a need for more than 256 algorithms, how should these be
> coded?  In binary or in ascii?  Fixed length or variable length?

ASCII, variable length.

I was kind of toying with the idea of creating a human readable formal
grammar which describes algorithm combinations.  Might save multiple
entries for DES (DES CBC, DES CFB, DES OFB, 3DES-EDE, etc.,etc), and
would allow you to "implement" a chosen mode just by specifying what
mode you wanted DES, and how to combine that to mutliple key DES.
Anyone for outer-CBC 5DES?

Plus how to deal with short last blocks, how you want the IV
constructed etc.

PGP seems pretty big as it is.

This could stop reinvention of the wheel, and hence reduce more code
bloat when new algorithms are added by providing a more flexible plug
in.  You provide the code for the encryption and decryption of one
block (ie ECB style).  You then describe the mode you want using the
grammar, and you're done.  If you want a new mode, or new short end
block treatment, you add one of those too.

So if I get bored one day and go implement that lot, your 2 byte field
might be pretty painful for me.  But a variable length string would be
a handy way for me not to confuse implementations without this
ability, without having to design whole new formats.

Don't worry about the above example ... but please lets have variable
length fields for some future proofing of the message layout.

PGP message spec already went through one set of fudging to work
around some pgp2.x message spec limitations which made it difficult to
extend in such a way as not to cause earlier implementations to barf,
lets use the experience to avoid doing the same thing with pgp3.

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Date: Fri, 8 Aug 1997 15:54:36 -0400
From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Re: PGP Message Exchange Formats Internet Draft 
Sender: [email-masked]

On Fri, 8 Aug 1997, Jurgen Botz wrote:

> [email-masked] wrote:
> > and I, for one, would not like to see 1,000 algorithms defined because no
> > two implementations would work together, or the program would need to be
> > larger than most hard drives.
> 
> It may seem that way, but if you think about it... cryptographic algorithms
> are usually /tiny/ pieces of code.  Often less than 1k of object code but
> even if it's 5k that's still only 5MB for 1000 of 'em... a lot smaller than
> MS Word or other such.  And besides, algorithms could be linked in dynamically
> at run-time.

How large are the S-Boxes for DES and CAST?  And what if 500 of the
algorithms are simply variants of the above with different s-boxes?  You
also need key setup, which seems to be different for each algorithm.

Linking them in dynamically doesn't shrink them, it simply scatters them
among 500 DLLs or one giant DLL, and if the only use of that DLL is for
PGP, it may as well be in the binary.

I have shared libraries for SSLeay and have taken to convert my crypto
code to use that instead, and even did the SSL for lynx in a generic proxy
(works with GNUscape for emacs too), which ends up around 20K under Linux
i386 for a full SSL server and client proxy that handles certificates.  Of
course PGP doesn't use any existing library for these functions, and
Netscape has its own internal Crypto and Bignums to do SSL, and the OS
internal stuff has another one... 

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 8 Aug 1997 15:22:19 -0400 (EDT)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: PGP Message Exchange Formats Internet Draft
Sender: [email-masked]

>And RIPEMD-160 would be indicated how?  Having length byte, text field
>may well be overkill.  So I'd suggest that a one byte ID with
>everything in an include file makes writing code easier, and doesn't
>need to change the presentation.

While four bytes might be overkill, I suspect that a single byte with only
255 possibilities (assume 0 means plaintext) may well be insufficient.

At least a word (16 bits/ 65535 possibilities) would seem more appropriate
particularly with so many varients of each (RC4-40, 56, 64, 128, ...).

Some may recall that IBM felt that one nibble was sufficient to define
all possible disk types in the CMOS in 1982 with Type 15 becoming a pointer 
to an extended table and 49 eventually becomming "define your own".

A word is used in UNIX to define TCP protocols, in 1981 (RFC 793) 255
probably would have seemed adequate for that use also.

					Warmly,
						Padgett

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Modular algorithms in PGP 5.0 (was Re: PGP Message Exchange Formats Internet Draft)
From: Derek Atkins <[email-masked]>
Date: 08 Aug 1997 14:59:25 -0400
Lines: 30
Sender: [email-masked]

Umm, I'm not sure what code you've seen, but if you look in
lib/pgp/crypt/cipher.c(*) and lib/pgp/crypt/hash.c(*), you will find
functions like "pgpGetCipherByNumber()", "pgpGetCipherByName()",
"pgpGetHashByNumber()", and "pgpGetHashByName()".  These could
_EASILY_ be re-implemented as dlopen() calls.

-dere

(*) These files are from a VERY old source code tree, circa October
1996.  The file names and function names may have changed between then
and now.  YMMV.

[email-masked] writes:

> But before this goes off on a tangent, PGP 5.0 (at least the source
> code I have seen) isn't modular in the sense of having a dlopen(alg) call,
> and I, for one, would not like to see 1,000 algorithms defined because no
> two implementations would work together, or the program would need to be
> larger than most hard drives.
> 
> This issue itself should limit the number of algorithms to 256 or less.
> 
> --- reply to tzeruch - at - ceddec - dot - com ---
> 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
       [email-masked]                        PGP key available

To: [email-masked]
From: Jurgen Botz <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: PGP Message Exchange Formats Internet Draft 
Date: Fri, 08 Aug 1997 08:54:12 -0700
Sender: [email-masked]

--==_Exmh_-1707635456P
Content-Type: text/plain; charset=us-ascii

[email-masked] wrote:
> and I, for one, would not like to see 1,000 algorithms defined because no
> two implementations would work together, or the program would need to be
> larger than most hard drives.

It may seem that way, but if you think about it... cryptographic algorithms
are usually /tiny/ pieces of code.  Often less than 1k of object code but
even if it's 5k that's still only 5MB for 1000 of 'em... a lot smaller than
MS Word or other such.  And besides, algorithms could be linked in dynamically
at run-time.

--==_Exmh_-1707635456P
Content-Type: application/pgp-signature

--==_Exmh_-1707635456P--

Date: Fri, 8 Aug 1997 09:56:48 -0400
From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Re: PGP Message Exchange Formats Internet Draft
Sender: [email-masked]

On Thu, 7 Aug 1997, Marshall Clow wrote:

> At 7:48 PM -0700 8/7/97, Adam Shostack wrote:
> >Jonathan Wienke wrote:
> >| Instead of having a 1-byte cipher identifier, I would like to see a 4 byte
> >| text identifier for ciphers and hashes, so IDEA could be designated by
> >| "IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it much
> >| easier for PGP to support numerous algorithms, and multiple encryption.
> >| Perhaps each algorithm could be implemented as a plug-in, so that
> >| encrypting a message with triple-DES, IDEA, and then something cooked up in
> >| your basement would be easily implemented.
> >|
> >And RIPEMD-160 would be indicated how?  Having length byte, text field
> >may well be overkill.  So I'd suggest that a one byte ID with
> >everything in an include file makes writing code easier, and doesn't
> >need to change the presentation.
> >
> As much a fan of 4 byte identifiers as I am, I agree with Adam here.
> We aren't going to see 2 billion or so cipher ids.
> 
> However, I can envision a day when we have more than 256 cipher IDs.
> 
> Two bytes, please (or octets, if you prefer)

You will need more than one byte, unless PGP wants to insist that only
their version of CFB is used for the internal complication.  There is now
a CBC(?) version of CAST, and the other variants deserve either another
chain/feedback byte, or we simply need a bigger integer to store it.

Just go to Applied Cryptography and start counting algorithms and then
ways to make the algorithms more complex, and multiply.

But before this goes off on a tangent, PGP 5.0 (at least the source
code I have seen) isn't modular in the sense of having a dlopen(alg) call,
and I, for one, would not like to see 1,000 algorithms defined because no
two implementations would work together, or the program would need to be
larger than most hard drives.

This issue itself should limit the number of algorithms to 256 or less.

--- reply to tzeruch - at - ceddec - dot - com ---

To: [email-masked], [email-masked]
Subject: PGP cipher tags
From: Assar Westerlund <[email-masked]>
Date: 08 Aug 1997 15:36:35 +0200
Lines: 46
Sender: [email-masked]

- Do we really need more than 256 algorithms _in PGP_?

There are and will be lots of new algorithms.  Even more if we take
into consideration the key size used.  But will/should all these
really be used and specified in PGP?

- Do we have to change the existing spec (and implementations) that
use 8 bits for specifying the algorithm?

These are the existing algorithms from section 6 of
draft-ietf-pgp-formats00.txt:

----------------------------------------------------------------------
6. Constants

This section describes the constants used in PGP Version 5.x.

6.1 Public Key Algorithms

1	-	RSA
16	-	Diffie-Helman, El Gamal variant
17	-	DSS (Digital Signature Algorithm)

6.2 Symmetric Key Algorithms

0	-	Plaintext
1	-	IDEA
2	-	Triple-DES (DES-EDE, 168 bit key)
3	-	CAST5 (128 bit key)

6.3 Compression Algorithms

0	-	Uncompressed
1	-	ZIP

6.4 Hash Algorithms

1	-	MD5
2	-	SHA-1
?	-	RIPE-MD/160
----------------------------------------------------------------------

- If there's a need for more than 256 algorithms, how should these be
coded?  In binary or in ascii?  Fixed length or variable length?

/assar

Date: Fri, 8 Aug 1997 08:57:49 -0400 (EDT)
From: Rich Salz <[email-masked]>
To: [email-masked]
Subject: Re: PGP Message Exchange Formats Internet Draft
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> Do you really see a new for more than 256 algoritms?

Some people (and incredibly big manufacturers of computers) are inclined
to consider 40bitRC4 a different algorithm from
128bitRC4.  So the answer to your question is "yes, trivially."
	/r$

Date: Fri, 8 Aug 1997 13:16:42 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: algorithm ID encodings & terminology (was Re: PGP Message Exchange Formats Internet Draft)
Sender: [email-masked]

knightPhlight <[email-masked]> writes:
> "640k should be more than enough memory for anybody." - Bill Gates

Cees de Groot <[email-masked]> writes:
> Some people didn't see a need for more than 640k, either...

Uncanny, same message simultaneously.

Anyway I side with knightPhlight -- 256 isn't enough, and 64k isn't
enough either.  Who knows what you'll need.  Make it a string.  It'll
only cost you one byte (or nothing compared to Cees's call for 2
bytes).

As another thing what happened to the unix philosphy of human readable
file formats?  Or at least file formats that you can reasonably pick
apart with a hex editor?

Why are PGP so keen to hand huffman encode everything?

(single bit fields, 1 byte identifier, variable length of length
fields etc.)

PRZ wrote PGP 1.0 for DOS first, perhaps this is why ... Personally I
would start over and use some thing that would cause pgp2.x to give up
gracefully as the first byte.

I can grant something for cleartext signatures perhaps, but other than
that it's hardly an issue.

If pgp are concerned about size at this nit-picking hand huffman
encoding level: they made the wrong choice with El Gamal, they
would've saved space with straight Diffie-Hellman, and not had to
generate so many random numbers as a bonus.  (A pgp employee who I
won't name admitted in the past when this issue was raised, oh well,
it's only a few bytes).

Another thing while I'm at it:

The constant use of Diffie-Hellman to refer to El-Gamal is misleading.
Is seems to get referred to as "Diffie-Hellman" with occasional note
that actually they mean El-Gamal, "a variant of Diffie-Hellman."

Is this mis-nomenclature motivated by a belief that more people will
have heard of Diffie-Hellman and hence get a warm fuzzy feeling or
something?

It's El-Gamal, damn it!

(re hand huffman encoding fun -- it's something I have practice at, my
sig is an implementation of RSA in perl and dc, which has been hand
compressed in such a way that it still functions -- even gzip can't
wring much out of it now -- actualy it gets bigger if you consider
that it is already seven bit clean).

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Date: Fri, 08 Aug 1997 12:37:39 +0200
To: [email-masked]
From: Hagen Wollert <[email-masked]>
Subject: Re: PGP Message Exchange Formats Internet Draft 
Cc: [email-masked]
Sender: [email-masked]

Hello to all,

at 09:39 08.08.1997 +0200 Cees de Groot (>) wrote:

>[email-masked] said:
>> Do you really see a new for more than 256 algoritms? 
>
>Some people didn't see a need for more than 640k, either...
>
>For this one byte, you step from likely exhaustion of your cypher-id space to 
>very unlikely exhaustion. If people pick this up, start experimenting, 
>etcetera - yes I can envision more than 256 algorithms. 65536, on the other 
>hand, should be enough.

Well, here are my 2 cents to this context: One of the most wide-spread and
commonly used graphic-file-format ist the well-known Tif-format: It has been
designed to be able to imply all future needs by specifying them in tags
when needed with the effect that programs are downward-compatible. Thus it
now lasts for at least 5 years which is a relatively long period compared
the lifetime of hard- & software.

I think one should reserve at least 4 bytes ( each consisting of 8 bits :-)
) of data thus being able to roughly specify algorithms in ASCII-digits ( (
each consisting of 7 bits preceded by a '0' ;-) ) or directly being able to
use 2**28 = 268,435,456 or even 2**31 = 2,147,483,648 different algorithms (
each or the first byte beginning with a '1' ). This is even more than any
key-sub-space commonly used by beginners.

Best regards,

Hagen

-- 
_____________________________________________________________________
Hagen Wollert                               [email-masked]
PGPed E-Mail welcome    -    public key available on most key-servers
2048/BBAF99CD   MD5: 11 AD A2 70 67 0A 32 CA  34 D8 F0 CE 67 8A B7 A1

Date: Fri, 8 Aug 1997 12:59:39 MET DST
From: Johnny Eriksson <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: PGP Message Exchange Formats Internet Draft 
Sender: [email-masked]

Assar wrote:

> Jonathan Wienke <[email-masked]> writes:
> > Instead of having a 1-byte cipher identifier, I would like to see a 4 byte
> > text identifier for ciphers and hashes, so IDEA could be designated by
> > "IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it much
> > easier for PGP to support numerous algorithms, and multiple encryption.
> 
> Do you really see a new for more than 256 algoritms?

No, but...  256 is a rather low value for infinity, no matter what you
are using it for.  2^32 is a low value for the max number of IP addresses,
but it looked more than enough a number of years ago.

We might not see a need for more than 256 types right now, but it's still
stupid to restrict things.  And having a 4-byte menmonic name is cute.

> /assar

--Johnny

To: Assar Westerlund <[email-masked]>
cc: Jonathan Wienke <[email-masked]>, Jon Callas <[email-masked]>, jude shabry <[email-masked]>, [email-masked], [email-masked]
Subject: Re: PGP Message Exchange Formats Internet Draft 
From: Cees de Groot <[email-masked]>
Reply-To: [email-masked]
Date: Fri, 08 Aug 1997 09:39:29 +0200
Sender: [email-masked]

[email-masked] said:
> Do you really see a new for more than 256 algoritms? 

Some people didn't see a need for more than 640k, either...

For this one byte, you step from likely exhaustion of your cypher-id space to 
very unlikely exhaustion. If people pick this up, start experimenting, 
etcetera - yes I can envision more than 256 algorithms. 65536, on the other 
hand, should be enough.

-- 
Cees de Groot               http://pobox.com/~cg         <[email-masked]>
Principal Consultant
OpenLink Software     http://www.openlinksw.com/    <[email-masked]>

To: Jonathan Wienke <[email-masked]>
Cc: Jon Callas <[email-masked]>, jude shabry <[email-masked]>, [email-masked], [email-masked]
Subject: Re: PGP Message Exchange Formats Internet Draft
From: Assar Westerlund <[email-masked]>
Date: 08 Aug 1997 05:46:39 +0200
Lines: 15
Sender: [email-masked]

Jonathan Wienke <[email-masked]> writes:
> Instead of having a 1-byte cipher identifier, I would like to see a 4 byte
> text identifier for ciphers and hashes, so IDEA could be designated by
> "IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it much
> easier for PGP to support numerous algorithms, and multiple encryption.

Do you really see a new for more than 256 algoritms?

> Perhaps each algorithm could be implemented as a plug-in, so that
> encrypting a message with triple-DES, IDEA, and then something cooked up in
> your basement would be easily implemented.

Having one byte doesn't stop you for implementing plug-ins.

/assar

Date: Thu, 7 Aug 1997 20:39:31 -0700
To: Adam Shostack <[email-masked]>, [email-masked] (Jonathan Wienke)
From: Marshall Clow <[email-masked]>
Subject: Re: PGP Message Exchange Formats Internet Draft
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 7:48 PM -0700 8/7/97, Adam Shostack wrote:
>Jonathan Wienke wrote:
>| Instead of having a 1-byte cipher identifier, I would like to see a 4 byte
>| text identifier for ciphers and hashes, so IDEA could be designated by
>| "IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it much
>| easier for PGP to support numerous algorithms, and multiple encryption.
>| Perhaps each algorithm could be implemented as a plug-in, so that
>| encrypting a message with triple-DES, IDEA, and then something cooked up in
>| your basement would be easily implemented.
>|
>And RIPEMD-160 would be indicated how?  Having length byte, text field
>may well be overkill.  So I'd suggest that a one byte ID with
>everything in an include file makes writing code easier, and doesn't
>need to change the presentation.
>
As much a fan of 4 byte identifiers as I am, I agree with Adam here.
We aren't going to see 2 billion or so cipher ids.

However, I can envision a day when we have more than 256 cipher IDs.

Two bytes, please (or octets, if you prefer)

-- Marshall

Marshall Clow     Aladdin Systems   <mailto:[email-masked]>

"In Washington DC, officials from the White House, federal agencies and
Congress say regulations may be necessary to promote a free-market
system." --  CommunicationsWeek International April 21, 1997

From: Adam Shostack <[email-masked]>
Subject: Re: PGP Message Exchange Formats Internet Draft
To: [email-masked] (Jonathan Wienke)
Date: Thu, 7 Aug 1997 22:48:49 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

And RIPEMD-160 would be indicated how?  Having length byte, text field
may well be overkill.  So I'd suggest that a one byte ID with
everything in an include file makes writing code easier, and doesn't
need to change the presentation.

Adam

Jonathan Wienke wrote:
| Instead of having a 1-byte cipher identifier, I would like to see a 4 byte
| text identifier for ciphers and hashes, so IDEA could be designated by
| "IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it much
| easier for PGP to support numerous algorithms, and multiple encryption.
| Perhaps each algorithm could be implemented as a plug-in, so that
| encrypting a message with triple-DES, IDEA, and then something cooked up in
| your basement would be easily implemented.
| 
| At 01:47 PM 8/7/97 -0700, Jon Callas wrote:
| >At 12:33 AM -0700 8/6/97, Hironobu Suzuki said:
| >
| >
| >   I'd like to know to contact a person to get new chiper identifier.
| >
| >That might as well be me. As we progress with making PGP a standard, we'll
| >be setting up a way to do that. If you don't need it right away, let the
| >list know what you want, and it will get on our to-do list. If you need it
| >right away, we'll get you one ASAP.
| >
| >	Jon
| >
| >
| >
| >-----
| >Jon Callas                                         [email-masked]
| >Chief Scientist                                    555 Twin Dolphin Drive
| >Pretty Good Privacy, Inc.                          Suite 570
| >(415) 596-1960                                     Redwood Shores, CA 94065
| >
| >
| >
| >
| 
| Jonathan Wienke
| 
| What part of "the right of the people to keep and bear Arms, shall not be
| infringed" is too hard to understand? (From 2nd Amendment, U.S. Constitution)
| 
| PGP 2.6.2 RSA Key Fingerprint: 7484 2FB7 7588 ACD1  3A8F 778A 7407 2928
| DSS/D-H Key Fingerprint: 3312 6597 8258 9A9E D9FA  4878 C245 D245 EAA7 0DCC
| Public keys available at pgpkeys.mit.edu. PGP encrypted e-mail preferred.
| 
| US/Canadian Windows 95/NT or Mac users:
| Get Eudora Light + PGP 5.0 for free at http://www.eudora.com/eudoralight/
| Get PGP 5.0 for free at http://bs.mit.edu:8001/pgp-form.html
| Commercial version of PGP 5.0 and related products at http://www.pgp.com
| Eudora + PGP = Free, Convenient Communication Privacy
| 
| Go postal! Write your mommy a letter!

[application/pgp-signature is not supported, skipping...]

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

Date: Thu, 07 Aug 1997 18:33:09 -0700
To: Jon Callas <[email-masked]>, jude shabry <[email-masked]>, [email-masked]
From: Jonathan Wienke <[email-masked]>
Subject: Re: PGP Message Exchange Formats Internet Draft
Cc: [email-masked]
Sender: [email-masked]

--=====_Eudora-PGP-Plugin6131==_
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Instead of having a 1-byte cipher identifier, I would like to see a 4 byte
text identifier for ciphers and hashes, so IDEA could be designated by
"IDEA", triple-DES by "3DES", SHA-1 by "SHA1", etc. This would make it much
easier for PGP to support numerous algorithms, and multiple encryption.
Perhaps each algorithm could be implemented as a plug-in, so that
encrypting a message with triple-DES, IDEA, and then something cooked up in
your basement would be easily implemented.

At 01:47 PM 8/7/97 -0700, Jon Callas wrote:
>At 12:33 AM -0700 8/6/97, Hironobu Suzuki said:
>
>
>   I'd like to know to contact a person to get new chiper identifier.
>
>That might as well be me. As we progress with making PGP a standard, we'll
>be setting up a way to do that. If you don't need it right away, let the
>list know what you want, and it will get on our to-do list. If you need it
>right away, we'll get you one ASAP.
>
>	Jon
>
>
>
>-----
>Jon Callas                                         [email-masked]
>Chief Scientist                                    555 Twin Dolphin Drive
>Pretty Good Privacy, Inc.                          Suite 570
>(415) 596-1960                                     Redwood Shores, CA 94065
>
>
>
>

Jonathan Wienke

What part of "the right of the people to keep and bear Arms, shall not be
infringed" is too hard to understand? (From 2nd Amendment, U.S. Constitution)

PGP 2.6.2 RSA Key Fingerprint: 7484 2FB7 7588 ACD1  3A8F 778A 7407 2928
DSS/D-H Key Fingerprint: 3312 6597 8258 9A9E D9FA  4878 C245 D245 EAA7 0DCC
Public keys available at pgpkeys.mit.edu. PGP encrypted e-mail preferred.

US/Canadian Windows 95/NT or Mac users:
Get Eudora Light + PGP 5.0 for free at http://www.eudora.com/eudoralight/
Get PGP 5.0 for free at http://bs.mit.edu:8001/pgp-form.html
Commercial version of PGP 5.0 and related products at http://www.pgp.com
Eudora + PGP = Free, Convenient Communication Privacy

Go postal! Write your mommy a letter!
--=====_Eudora-PGP-Plugin6131==_
Content-Type: application/pgp-signature

--=====_Eudora-PGP-Plugin6131==_--

Date: Thu, 7 Aug 1997 13:47:37 -0700
To: Hironobu Suzuki <[email-masked]>, jude shabry <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: PGP Message Exchange Formats Internet Draft
Cc: [email-masked]
Sender: [email-masked]

At 12:33 AM -0700 8/6/97, Hironobu Suzuki said:

   I'd like to know to contact a person to get new chiper identifier.

That might as well be me. As we progress with making PGP a standard, we'll
be setting up a way to do that. If you don't need it right away, let the
list know what you want, and it will get on our to-do list. If you need it
right away, we'll get you one ASAP.

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065

Date: Thu, 7 Aug 1997 13:32:21 -0700
To: Noah Salzman <[email-masked]>, "A. Padgett Peterson P.E. Information Security" <[email-masked]>, <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: RE: content tag, format, terminology
Cc: <[email-masked]>
Sender: [email-masked]

As the person who is guilty of using the word "octet" in the draft, and who
encouraged others to do the same, I suppose I should say why I did.

When I was lobbying for it, I said, "'octet' is the politically correct way
to say 'byte'" and gave pretty much the same explanations that Padgett and
others did. Once, long ago, there were other size bytes than the ones that
ones we're all used to. I agree that it's an odd term, and one that makes a
lot of people just wonder.

I can think of a couple of easy solutions. One is that we put in a
paragraph explaining that an octet is a PC byte (in more ways than one).
Another is that we change all the uses of "octet" to "byte" and put in a
paragraph explaining that for this documentation, when we say "byte" we
mean an eight-bit byte, the type that many other standards call an octet.
Either is fine with me.

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065

Date: Wed, 6 Aug 97 21:23:23 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: Re: terminology
Sender: [email-masked]

Folks, I've also been around since Baudot days, and am familiar with at
least some of the different sized historic bytes.  That's why I think we
should specifically define the meaning in a terminology section.

As opposed to the 9 in 36 mentioned, another of the byte sizes is 6 in 36
and 6 in 60 for the CDC 3000 and 6000 series respectively.

I used octet throughout PPP specifications, to be least confusing to
folks reading ISO, CCITT and IETF documents in parallel.

I use byte in other venues.  In any case, the terms should be well
defined, and cognizant of the intended reader.

The problem that I raised was that _both_ byte and octet are used in the
same document.  Pick one.  Be consistent and readable.  Thank you.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: RE: content tag, format, terminology
Cc: [email-masked]
Reply-To: [email-masked]
Date: Thu, 7 Aug 1997 06:55:19 (NZST)
Sender: [email-masked]

>>byte             An 8-bit quantity; also known as "octet" in
>>                 standardese.
>
>Just a loint of paw but a byte is not always 8 bits though this is
>the common assumption today. If you asked an IBMer in 1981, the answer
>was 9 bits. To a Baudot type it would be five bits.
  
I knew someone was going to come up with this... in reply I'll post a classic 
flame of this sort of thing from Markus Kuhn.  Followups to... well, somewhere 
else I guess.
 
Peter.
 
>Newsgroups: comp.text.sgml,comp.std.internat
>From: [email-masked] (Markus Kuhn)
>Subject: Silly ISO terminology (was: UTF)
>Date: Tue, 11 Apr 1995 10:02:09 GMT
>
>I know very well that UTF means
>
>  Universal Multiple-Octet Coded Character Set Transformation Format.
>
>Some ISO committees have a real talent for effective anti-marketing by
>introducing lots of abbreviations which only support the common theory that
>some ISO standards have been written by little green monsters from outer space
>in order to confuse normal human beings and prepare them for the big invasion.
>Who can remember 'Universal Multiple-Octet Coded Character Set Transformation
>Format' easily without checking the standard?
>
>Why means UCS 'Universal Multiple-Octet Coded Character Set' and not simply
>much easier to remember 'Universal Character Set'? Why do we use strange
>terminology like 'octet' while today every 10-year old kid learns at school
>that 'byte' means 'an 8-bit binary number used in computers to store
>information'. Why use many character set standards still the extremely exotic
>08/15 notation for bytes (sorry, octets ;-) instead of the hexadecimal notatio
>used by everyone else all over the world.
>
>Markus
 
Peter.

Subject: RE: content tag, format, terminology
Date: Wed, 6 Aug 97 11:37:25 -0700
From: Noah Salzman <[email-masked]>
To: "A. Padgett Peterson P.E. Information Security" <[email-masked]>, <[email-masked]>
cc: <[email-masked]>
Sender: [email-masked]

A. Padgett Peterson P.E. Information Security 
([email-masked]) wrote this on 8/6/97 11:25 AM:

>Just a loint of paw but a byte is not always 8 bits though this is
>the common assumption today. If you asked an IBMer in 1981, the answer
>was 9 bits. To a Baudot type it would be five bits.
>
>The original definition was "that number of bits required to define
>an alphanumeric character" (including some punctuation) so varied by
>platform.
>
>Now if you wish to define it as such, that is fine however "octet" is the
>correct and specific term for eight bits.

Since you brought it up, here is a little more info on byte length from:

http://nightflight.com/foldoc/
(The Free Online Dictionairy of Computing)
-------------------

byte

<unit>  A component in the machine data hierarchy usually larger than a 
bit and smaller than a word; now most often eight bits and the smallest 
addressable unit of storage. A byte typically holds one character. 

A byte may be 9 bits on 36-bit computers. Some older architectures used 
"byte" for quantities of 6 or 7 bits, and the PDP-10 and IBM 7030 
supported "bytes" that were actually bitfields of 1 to 36 (or 64) bits! 
These usages are now obsolete, and even 9-bit bytes have become rare in 
the general trend toward power-of-2 word sizes. 

The term was coined by Werner Buchholz in 1956 during the early design 
phase for the IBM Stretch computer. It was a mutation of the word "bite" 
intended to avoid confusion with "bit". In 1962 he described it as "a 
group of bits used to encode a character, or the number of bits 
transmitted in parallel to and from input-output units". The move to an 
8-bit byte happened in late 1956, and this size was later adopted and 
promulgated as a standard by the System/360 operating system (announced 
April 1964). 

James S. Jones <[email-masked]> adds: 

I am sure I read in some historical brochure by IBM some 15-20 years ago 
that BYTE was an acronym that stood for "Bit asYnchronous Transmission 
E__?__" which related to width of the bus between the Stretch CPU and its 
CRT-memory (prior to Core). 

See also nybble, octet.

Date: Wed, 6 Aug 1997 14:25:37 -0400 (EDT)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: RE: content tag, format, terminology
Sender: [email-masked]

>   byte             An 8-bit quantity; also known as "octet" in
>                    standardese.

Just a loint of paw but a byte is not always 8 bits though this is
the common assumption today. If you asked an IBMer in 1981, the answer
was 9 bits. To a Baudot type it would be five bits.

The original definition was "that number of bits required to define
an alphanumeric character" (including some punctuation) so varied by
platform.

Now if you wish to define it as such, that is fine however "octet" is the
correct and specific term for eight bits.

					Warmly,
						Padgett

Date: Wed, 6 Aug 97 14:51:12 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: content tag, format, terminology
Sender: [email-masked]

There is a general problem with inconsistent terminology.

I suggest that "octet" be changed everywhere to "byte", with a short
section defining byte.  Here's what I use:

1.1.  Terminology

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [RFC-2119].

   byte             An 8-bit quantity; also known as "octet" in
                    standardese.

====

The term "packet" is simply wrong.  A packet is a link-layer term.

I suggest that "packet" be changed everywhere to "element", which would
be consistent with other sections of the draft, including section titles
using element.

====

And then there is the problem of the "cipher type byte", which does not
define a cipher, and which contains a "tag".  Please change the name to
"Content Tag Byte", which should not be too hard.

Many of the possible combinations of the CTB are not legal, or are never
generated.  The draft is confusing.  A better organization would be a
simple tabular list of the legal values and formats of the CTB.

Here's what I suggest:

hex     element                                 length  version
===     =======                                 ======  =======
00..83  Reserved
84      Public-Key-Encrypted Session-Key        1-byte  2.3.x
85      Public-Key-Encrypted Session-Key        2-byte  2.6.x
86..87  Reserved
88      Signature                               1-byte  2.3.x
89      Signature                               2-byte  2.6.x
8A..93  Reserved
94      Secret-Key
(etc.)
  ..C0  Reserved
C1      Public-Key-Encrypted Session-Key        n-byte  5.0.x
C2      Signature                               n-byte  5.0.x
(etc.)

Reserved.  A CTB MUST NOT have a tag with this value.

====

And that n-byte length definition needs work.  Very hard to understand.

Worse, it is really rather ugly.  Why have the 0..191 1-byte variant?
Why not start with 2-byte length for everything?  Are we really
encouraging smaller than 256-bit moduli?

OK, I suppose we are stuck with 0..191 for compatibility.

But the next step should be changed.  After all, you are bringing this
to the IETF for standardization; the IETF will have change control.

That power of two variant should be tossed.  Is it ever used?

In this case, I recommend that the stepping be this:

hex     decimal length  formula
===     ======= ======  =======
00..BF  to 191  1-byte  0 .. 191
C0..EF  to 239  2-byte  ((b[1] - 192) * 256) + b[2] + 192
                aka     b[1..2] - 2**15 - 2**14 + 192
                aka     b[1..2] - 48,960
                aka     192 .. 16,575
F0..FB  to 251  3-byte  b[1..3] - 2**23 - 2**22 - 2**21 - 2**20 + 16,576
                aka     16,576 .. 1,065,151
                aka     much too much for IP
FC..FF  to 255          reserved

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

To: jude shabry <[email-masked]>
Cc: [email-masked]
Subject: Re: PGP Message Exchange Formats Internet Draft 
Date: Wed, 06 Aug 1997 16:33:00 +0900
From: Hironobu Suzuki <[email-masked]>
Sender: [email-masked]

>From Opening Message.

> - new cipher suites (elliptic curve, other symmetric ciphers) and
>   cipher identifiers

>From Internet Draft
>6. Constants
>* 6.1 Public Key Algorithms
>* 6.4 Hash Algorithms

I'd like to know to contact a person to get new chiper identifier.

-- 
Hironobu SUZUKI        Independent Software Consultant
Tel: +81-3-5310-7303   Fax: +81-3-5382-7065
E-Mail: [email-masked]
3-42-19-306, Nishiogi Kita, Suginami, Tokyo, 167, JAPAN.

Subject: Re: PGP Message Exchange Formats draft-ietf-pgp-formats00.txt
Date: Sun, 3 Aug 97 03:48:53 +0200
From: Gerald Young <[email-masked]>
To: "jude shabry" <[email-masked]>
cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 7/31/97 02:02, jude shabry <[email-masked]> wrote:
>INTERNET-DRAFT						      Gail Haspert
>Security						            PGP, Inc.
>Expires in six months					Editor             
>							                   July 30 1997
>
>PGP Message Exchange Formats
><draft-ietf-pgp-formats00.txt>
>

Some comments on the contents, syntax and semantcs of the =
aforementined document.

Regards
-- Gerald

-BEGIN-
> 2.4 Radix-64 conversion

>  ...converting    
>  the raw 8-bit binary octet stream to a stream of printable ASCII   
>  characters, called Radix-64 encoding or ASCII Armor.

Isn't the term "octet" a synonym for 8-bit data entities, defined as =
such in RFC ????

"ASCII characters" are really "7-bit US-ASCII octets"

>  Similar to MIME encoding, the process of Radix-64 encoding an

MIME defines several encodings, use an explicit reference to "base64" =
encoding
(RFC ???? Section ?.?)

>  ...8-bit binary stream of data...

"binary octet stream"

>  is as follows. Every three subsequent 8 bit binary octets...

simply "octets" instead of "8 bit binary octets" (8-bit binary =
octets).

>  are mapped into four subsequent 6-bit ASCII characters.  

what are 6-bit ASCII characters? use "US-ASCII". "6-bit coding subset =
of US-ASCII"

In general the process is already defined and phrased in some MIME =
documents, so
that wording SHOULD be used for consistency IMHO.

>  Radix-64 encoding also appends a CRC to detect transmission errors.

This really is a difference from base64.

How is padding handled? This is explicitely stated in base64 specs.

>  This radix-64 conversion, is a wrapper around the binary PGP   
>  messages, and is used to protect the binary messages during 
>  transmission over non-binary channels, such as Internet Email.

How does this interoperate with 8bitMIME capable ESMTP mailers? =
Explicite reference.

>  The following table defines the mapping.  The characters used are the
>  upper- and lower-case letters, the digits 0 through 9, and the
>  characters + and /.  The carriage-return and linefeed characters
>  aren't used in the conversion, nor is the tab or any other character
>  that might be altered by the mail system. The result is a text file
>  that is "immune" to the modifications inflicted by mail systems.

Is this anyhow different to MIME base64 encoding?

>  To encode an arbitrary 3 octets, separate the bit stream logically

how is an octet transformed into an bit stream, which bit is first...?

>  into four 6-bit groups, calculate the decimal value of the 6-bit

"decimal value" ??? decimal is because of the table below, but not
required by the encoding process? skip "decimal", use "use as an =
index".

>  group, and replace it with the corresponding character from the table 
>  below.

>  Decoding is the exact opposite operation.

Really? Nothing more :) This is a to-be standard, defining things not =
merely
stating them to happen...

Add one or more paragraphs on decoding...

>                  6-bit Value Mapped to Character Encoding

See? no "decimal" mentioned in the table heading

>           Hex octet           0x17      0x3A      0xA3
>Example:   Binary stream      00010111  00111010  10100011
>           Translate to 6bit  000101  110011  101010  100011
>           Decimal              5      51      42      35
>          Final Character       F       z       q       j

OK, this serves as example and definition on bit-streaming...

But, what to to if there are not enough octets as input, how to pad?
And how to detect the end of the to-be-decoded stream, as there is no
length field anywhere...

>  It is possible to use PGP to convert any arbitrary file to ASCII
>  Armor.  When this is done, PGP tries to compress the data before it
>  is converted to Radix-64.

Terms "ASCII Armor" and "Radix-64" are used interchangable, by =
intention.

What about MIME base64 content encoding of "binary" PGP message data?

binary data --> ASCII Armor (as per 2.4.1 below) --> compress ? -->
Radix-64 ---> MIME...

>2.4.1 ASCII Armor Formats
>
>  When PGP encodes data into ASCII Armor, it puts specific headers
>  around the data, so PGP can reconstruct the data at a future time.
>  PGP tries to inform the user what kind of data is encoded in the
>  ASCII armor through the use of the headers.
>
>  ASCII Armor is created by concatenating the following data:

ok, we are now creating ASCII Armor...

>
>       - An Armor Headerline, appropriate for the type of data
>       - Armor Headers
>       - A blank line

What is a line, BTW. Obviously now we need an RFC822 type definition
of "line" (sequence of octets terminated by an <CR><LF> sequence?)

>       - The ASCII-Armored data

Oops. This is an recursive definition, as we are about to specify how
ASCII-Armored data is created. Obviously this should read
"The Radix-64 encoded data"

>       - An Armor Checksum

Same as above, should read "An Radix-64 Checksum of the encoded data".

>       - The Armor Tail, which depends on the Armor Headerline.

>  An Armor Headerline is composed by taking the appropriate headerline
>  text surrounded by five (5) dashes (-) on either side of the

(-) --> (US-ASCII 0x?? "-")

>  headerline text.  The headerline text is chosen based upon the type
>  of data that is being encoded in Armor, and how it is being encoded.

Is it "Armor" or "ASCII Armor" or "ASCII-Armor" or what?

>  Headerline texts include the following strings:

Is an enumeration to follow or an example?

>   BEGIN PGP MESSAGE -- used for signed, encrypted, or compressed files
>   BEGIN PGP PUBLIC KEY BLOCK -- used for transferring public keys 
>   BEGIN PGP MESSAGE, PART X/Y -- used for multi-part messages, where
>                                   the armor is split amongst Y files,
>                                   and this is the Xth file out of Y.

Use a tabular approach here, like:

    "BEGIN PGP MESSAGE"            used for signed, encrypted, or
                                   compressed files
                                 
    "BEGIN PGP PUBLIC KEY BLOCK"   used for transferring public keys 
    
    "BEGIN PGP MESSAGE, PART X/Y"  used for multi-part messages, where
                                   the armor is split amongst Y files,
                                   and this is the Xth file out of Y.

Make clear whether this is an exhaustive list ("definition") or only
examples.

How are new value strings introduced, and what to to with 
undefined/unkown strings.

>  The Armor Headers are pairs of strings that can give the user or the
>  receiving PGP message block some information about how to decode or   
>  use the message.

Strange concept, however :)

>  ...The Armor Headers are a part of the armor, not a 
>  part of the message, and hence should not be used to convey any    
>  important information, since they can be changed in transport.

How could this happen, they are to contain base64/radix-64 characters
considered to be mail save. Any other encoding of the "ASCII Armor" is
to be transparent and is removed/reversed before the ASCII Armor is
passed to the PGP layer.

What about BINARY Armor? Maybe introduce something streamable like =
GIF or PNG.

>  The format of an Armor Header is that of a key-value pair.  PGP 
>  should consider improperly formatted Armor Headers to be corruption 
>  of the ASCII Armor.  Unknown keys should be reported to the user, but 
>  PGP should continue to process the message. Currently defined Armor 
>  Header Keys include "Version" and "Comment," which define the PGP 
>  Version used to encode the message and a user-defined comment.

This paragraph obviously deals with the above mentioned "Armor =
Headerlines",
not "Armor Headers".

Armor Headerlines are to be built after RFC822 lines, thus possibly =
adopting
the folding and encoding (Q-encoding) rules defined there and =
elsewhere.

Thus Headerlines are just like "Subject:" or "Comment:" header lines =
of email
messages.

>The Armor Checksum is a 24-bit CRC converted to four characters of 
>radix-64 encoding, prepending an equal-sign (=3D) to the four character =
code.

"... to the resulting four characters."

>The CRC is computed by using the generator 0x864CFB and an initialization 
>of 0xB704CE.  The accumulation is done on the data before it is converted 
>to radix-64, rather than on the converted data.  For more information on 
>CRC functions, the reader is asked to look at chapter 19 of the book 
>"C Programmer's Guide to Serial Communications," by Joe Campbell.

This complete para above is not intented properly.

Got the ISBN of that book. A References section is missing from the =
draft.

>  The Armor Tail is composed in the same manner as the Armor
>  Headerline, except the string "BEGIN" is replaced by the string
>  "END."

Its "Headerline", but "Tail"; maybe use "Tail line" and "Header line".

An example of a short message in ASCII Armor is missing here now.

>3. Data Element Formats
>This section describes the data elements used by PGP.

An empty line is missing as seperator.

>3.1 Scalar numbers
>
>Scalar numbers are unsigned, and are always stored in big-endian format. 
>Thus, the value of a two-octet scalar is ((n[0] << 8) + n[1]). The value 
>of a four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + =
n[3]).

Add example.

>The string of octets [00 01 01] forms an MPI that has a value of 1. The =
string 
>[00 09 01 ff] forms an MPI with the value of 511.

reformat into seperate paragraphs and use uppercase characters for =
hex digits A..F.

--> The string of octets [00 01 01] forms a MPI that has a value of 1.
-->
--> The string of octets [00 09 01 FF] forms a MPI with the value of =
511.

Hmm, thus MPI's are quite different from Radix-64 bit streams, as the =
bit stream
is aligned differently. But:

>Additional rules:
>
>The size of an MPI is ((MPI.length + 7) / 8) + 2.

--> The size of a MPI in octets is ((MPI.length + 7) / 8) + 2.
                =3D=3D    =3D=3D=3D=3D=3D=3D=3D=3D=3D

>The length field of an MPI describes the length starting from its most 
>significant non-zero bit. Thus, the MPI [00 02 01] is not formed =
correctly.
>It should be [00 01 01].

This clears things up a bit, but this should be placed before the =
Example anyway.

Is it "an MPI" or "a MPI" ?!

>3.3 Strings
>
>A string consists of a one-octet length and then N octets of string data.

"an (!) one-octet", better "an one-octet scalar number specifying the =
length,
followed by that number of octets of string data."

Add an example, say "PGP".

>3.4 Time fields
>
>A time field is a four-octet number containing the number of seconds 
>elapsed since midnight, 1 January 1970 GMT.

"four-octet scalar number". Is this the UNIX epoch...

Give one example (maybe 1 January 2000 :) ) and give the maximum =
date/time possible
(not taking leap seconds and such into account...:) )

>4.2 Packet Headers
>
>The first octet of the packet header is called the "Cipher Type Byte."

"Byte" is ambiguous?! Define "ctb" or "CTB" used below.

This first octet is also the first octet of the entire packet, or =
else?

And, packets headers are obviously not covered by section 3, as they =
are not
defined there (an design flaw of early times, I guess).

Are "Tags" (as mentioned in 4.1 Overview) always single octets, then =
they can
be defined in section 3.

>In an old format packet, the packet tag resides in the middle four bits
>((ctb & 0x3c) >> 2). The two low order bits (ctb & 0x3) denote the number 

use "0x3C"

>of octets following the CTB that hold the length of the packet body.

"length" --> "length-type"

Thus with ((ctb & 0xFC) >> 2) --> 64..127 for old formats...

>The meaning of the length-type is:

>0 - The packet has a one-octet length. The header is 2 octets long.
>1 - The packet has a two-octet length. The header is 3 octets long.
>2 - The packet has a four-octet length. The header is 5 octets long.
>3 - The packet is of indeterminate length. The header is 1 byte long, 
>and the application must determine how long the packet is. If the packet 
>is in a file, this means that the packet extends until the end of the =
file. 
>In general, an application should not use indeterminate length packets.

Use table format:

  0   The packet has a one-octet length. The header is 2 octets long.

  1   The packet has a two-octet length. The header is 3 octets long.

  2   The packet has a four-octet length. The header is 5 octets long.

  3   The packet is of indeterminate length. The header is 1 byte =
long, 
      and the application must determine how long the packet is. If =
the packet 
      is in a file, this means that the packet extends until the end =
of the
      file.

  In general, an application should not use indeterminate length =
packets.

>In a new format packet, the low-order six bits (cth & 0x3f) form the =
packet
>tag.

The above text on old format packets used "ctb"?! 0x3F

>If the next octet is 191 or less, then that is the length of the packet

Use "second octet".

>body. If that octet is between 192 and 223, then the length of the packet 
>body is held in the two octets following the CTB with the following =
formula:

Another design flaw with v5.0: why not use MPI's here too.

Start a new para for the 192 to 223 case and maybe use also "second =
octet".

Rephrase to "high-order bit clear" type of description. Maybe use hex =
numbers
here too. "CTB" used here again, should be "ctb"?

>   bodyLen =3D ((p[1] - 192) * 256) + p[2] + 192;

what is p obviously pointing to?

>Note that this yields a maximum packet body length of 8383 octets for this
>type of packet.
>
>If the second octet is 224 or greater (note that 224 is E0 in =
hexadecimal, or 

"If that octet is between 224 and 255...", "0xE0" (you already used =
the
uppercase here)

>11100000 in binary), then the low-order five bits form the length of the 
>packet body with the formula:
>
>   bodyLen =3D 1 << (p[1] & 0x1f);
>
>In English, the packet body length is a power of two. Its maximum length 
>is 2**31 octets long. Note that there is no way to form a new-format =
packet 
>that is longer than 8383 octets and not a power of two in length.
>
>Please note that in all of these explanations, the total length of the
>packet is the length of the header plus the length of the body.

>4.3 Packet Tags
>
>The packet tag denotes what type of packet the body holds. Note that old
>format packets can only have tags less than 16, whereas new format =
packets 
>can have tags as great as 63. The defined tags are:
>
>0  -- Reserved. A packet must not have a tag with this value.
>1  -- Encrypted Session Key Packet

This table uses yet another format... unify.
Use Obsolete and Reserved and New as First descriptive element, maybe =
form
another column.

What to to with undefined packet tags encountered?

Packet Tag 16 is a new (v5.0) packet type?!

>5.0 Packet Types
>
>This section describes some of the more interesting packet types.

Rephrase. This is the definition document, should describe all packet =
types?!

>5.1 Encrypted Session Key Packets

Add packet tag value to the heading: "5.1 Encrypted Session Key =
Packets (Packet
Tag 1)"

>The body of this packet consists of:
>
>       - A one-octet number giving the version number of the packet type,
>        either 2 or 3. All modern versions of PGP generate type 3   
>        packets.

Give a complete desciption (is 0 valid, what about 1, how to =
decode...)
"All modern versions of PGP MUST generate type 3 packets and SHOULD =
decode type
2 packets."

>- An eight-octet number that gives the ID of the public key that 
>  the session key is encrypted to.
>       - A one-octet number giving the public-key algorithm used.

Definition of values is where?

>- A string of octets that is the encrypted session key. This 
>  string takes up the remainder of the packet, but is not     
>  explicitly counted.

"...and is thus not explicitely counted."

Intention is off...
use "scalar" instead of "number" to keep term consistent in this =
document.

>5.2 Conventional Encrypted Session-Key Packets

"5.2 Conventional Encrypted Session-Key Packets (Packet Tag 3)"
What about tag 2?

>This packet (tag 3) describes a session key that has been encrypted to a

omit "(tag 3)"

>secondary symmetric cipher. This allows a message to be encrypted to a
>number of public keys, and also to one or more pass phrases. This packet 
>type is new, and is not generated by PGP 2.x or PGP 5.0.

What about PGP 1.x or 0.x?

>The body of this packet consists of:
>	- A one-octet version number. The current version is 4.

Other versions, MUST, SHOULD... as above.

>	- A one-octet number describing the symmetric algorithm used.

Definitions...where?

>	- A "string-to-key" object. This is described below. It is 2, 10,   
>        or 11 octets long.
>	- The encrypted session key itself, which is decrypted with the
>        string-to-key object.

Table Intention is off...

>The string-to-key object has this format:
>
><To be written in a future draft.>

Sure :)

For other packet tags formattings needs to be chacket, headers should =
add the tag value. and missing descriptions and value definitions =
given

>5.9 User-Name Packet
>
>A user-name packet is a counted string with a one-octet length. By
>convention, it is an RFC 822 mail name, but there are no restrictions on =
its >content.

add tag value; what is "a (!) RFC mail name". Give an example. =
Possibly the mailbox name is meant (as in a To:,CC:,BCC: spec. Or =
"e-mail address"?

>6. Constants
>
>This section describes the constants used in PGP Version 5.x.

What about compatibility with previous (and future) versions?!

Following tables need to be adapted to document standard.

>7. Transferable Public Keys
>
>   Public keys may transferred between PGP users. The essential elements
>   of a transferable public key are:

Intention is off..

>8.1 Key Structures

>Each signature certifies the RSA public key and the preceding UserID.
>The RSA public key can have many UserIDs and each UserID can have
>many signatures.

Use either "User ID" or "UserID" for consistency.

>8.2 Public Key Certificate Packet Structure 
>
>To accommodate the addition of the subkey construction, a new
>version of the public-key-certificate packet was created.  Packets
>with a version of '3' are still created for PGP keys that use RSA

use either "version 3" or "version '3'" cnsistently.

>public keys.  For specifics on version 3 packets, see RFC 1991.
>The terms and formatting used here are consistent with that RFC.

"with that RFC"--> "with that document"

>RSA Public Key Certificate Packet ("old format")
>
>    a) packet structure field with CTB bits 5-2 =3D 0110 (2 or 3 bytes);
>    b) version number =3D 3 (1 byte);
>    c) time stamp of key creation (4 bytes);
>    d) validity period in days (0 means forever) (2 bytes);

This table should be formatted according to previous table samples.

And use octets instead of bytes, and two-octets and so on...

>8.7 Future Formats 
>
>Additional information on PGP formats is being provided to the public in
>order for others to build compatible or complimentary systems that
>support PGP.  

Eh?

And:

Add reference/bibliography and how to reach the author/working =
group....

-END-
=8A