Subject: critical bit (5.2.3.1)

From: Werner Koch <[email-masked]>
Date: Wed, 30 Sep 1998 10:38:36 +0200

From section 5.2.3.1:

> Bit 7 of the subpacket type is the "critical" bit.  If set, it
> denotes that the subpacket is one that is critical for the evaluator
> of the signature to recognize.  If a subpacket is encountered that
> is marked critical but is unknown to the evaluating software, the
> evaluator SHOULD consider the signature to be in error.

Can we restrict the SHOULD to hashed subpackets?  Otherwise it is
easy to invalidate a signature by setting the critical bit in a
unhashed subpacket.

  Werner

---

From: Jon Callas <[email-masked]>
Date: Wed, 30 Sep 1998 13:59:14 -0700

At 10:38 AM 9/30/98 +0200, Werner Koch wrote:

Remember what SHOULD means:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

If you, as a developer, believe that there is greater danger in the
potential denial-of-service attack from critical unhashed subpackets than
there is value from them, you are free to ignore it.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 30 Sep 1998 13:59:14 -0700
To: Werner Koch <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: critical bit (5.2.3.1)
Sender: [email-masked]

At 10:38 AM 9/30/98 +0200, Werner Koch wrote:

Remember what SHOULD means:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

If you, as a developer, believe that there is greater danger in the
potential denial-of-service attack from critical unhashed subpackets than
there is value from them, you are free to ignore it.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 30 Sep 1998 13:48:57 -0700
To: Ian BROWN <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: error in draft 07, section 5.1 ?
Sender: [email-masked]

At 10:13 AM 9/30/98 +0200, Ian BROWN wrote:
   >Yes, you appear to be correct.  The algorithm identifier is not included
   >in the checksum.
   
   Did nobody notice the three messages that Ulf Moller and I sent about this 
   starting more than a month ago?
   
I noticed. The -07 draft had modifications in it from your comments.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 30 Sep 1998 14:29:51 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Sender: [email-masked]

Regarding the need for business access to encrypted communications --
I agree that the need is not strong, and I would hate to have to make the business case for a product that had that as its central justification, but there are valid examples outside of the military/intelligence community.

You might want to look at the key Recovery Alliance's web site www.kra.org for the Business Scenarios report, which addresses some of these needs for business key recovery, even for transitive communications.

Examples include review of outgoing communications by stock brokers to ensure that they are not engaging in insider trading (I believe this is imposed by law), companies who may have a positive duty to investigate a claimed case of sexual harassment, internal investigations of possible fraud or theft of trade secret information, etc.

Completely independent of these scenarios, there may be an additional requirement for server-based encryption of outgoing e-mail to support disconnected operation.

If a user composes an email message on his laptop while on an airplane, he may not have access to the recipient's certificates, and in particular, almost surely does not have access to the current CRLs.  Since the message can't be transmitted until the user reconnects, it may be acceptable and perhaps even desirable to have the server perform the encryption in the recipient's public key, after checking the CRLs, without necessarily making the user wait for all this while he is on a pay phone in the airport.  This doesn't mean that the information goes from the client to the server in the clear -- a symmetric key could easily be used.  

On the other hand, the checking of the certificates could be deferred, and the outgoing mail returned if the certificate has expired or been revoked. This would not require the server to be trusted.  

Obviously most users would probably prefer this option, but in most companies the users don't buy the software does, the IS department does, and their needs may therefore dominate.

Caveat emptor.

Bob

>>> William Ottaway <[email-masked]> 09/29 1:56 AM >>>
At 18:48 28/09/98 +0100, Adam Back wrote:
>
>Bill Ottaway writes:
>> However, organisations want to control the release of messages from their
>> employees.  They want to make sure outgoing messagers do not contain any
>> sensitive information or viruses. If the sender encrypts his mail
>> using the recipients key the organisation can not perform any of
>> these checks.
>
>Snooping outgoing email for sensitive information isn't a general
>commercial requirement.
>
>It is predominantly a government / signals intelligence special
>interest goal.
>
>UK's DERA (Defense Research Agency) / GCHQ designed the CASM protocol
>to allow snooping on sent and received email.
>
>CASM is partly based on server encryption.  Bill works for DERA
>(dera.gov.uk), so I am wondering if he is thinking of CASM in his
>comments, in that some of his arguments are couched in terms of a
>desire for mail snooping, while others were discussing server
>decryption purely in terms of ease of deployment, and adding blanket
>super-encryption, security and forward-secrecy for email that would
>otherwise not be encrypted.
>

No I wasn't thinking of CASM. I was just making a point that certain
organisations will want to be able to check their employees email for one
reason or another, this is not a military/government only issue.

Once companies start signing outgoing mail, which they will do, they are
taking some responsibility for the contents of that message. If that
message contained a virus then they could be sued for damage caused by that
virus. Signing is also a powerful mechanism which can be used in financial
transactions. Joe Blogs might not have the authority to perform financial
transactions, but a rubber seal from his organisation does carry the this
authority. This sort of transaction may need to be encrypted so that other
commercial organisations do not get wind of what you are up to. 

Yes the military and government have sensitive information which they do
not want to be mailed out of their organisations, but so do commercial
organisations (e.g. trade secrets, research, etc). This may not be a
requirement of all commercial companies but it still needs to be taken into
account when considering signing and encrypting messages. 

I would expect all large organisations, military, government or commercial
to require the ability to check employees email and to do
encryption/signing by the organisation.

>(CASM includes a form of GACK involving recomputing seed material, for
>details see:
>
>	http://www.opengroup.org/public/tech/security/pki/cki/ 
>
>)
>
>(As an aside, IMO, CASM is not a very elegant protocol: it has many
>online messages, uses public key crypto where symmetric could acheive
>the same effect with equal security, and has a centralised risk of the
>seed material of the root node of the hierarchy being compromised.)
>
>Shared keys or server encryption copes with multiple recipients
>needing to be able to decrypt messages (the `sales team' scenario).
>
>Server encryption is useful to augment personal key based security,
>and/or to speed deployment of "some" encryption even if not at first
>cut personal key based.
>
>I agree with Bill's comments about reduced PKI overhead of server
>based crypto, and his ease of deployment comments.
>
>Adam

Bill.

From: "Tim Dierks" <[email-masked]>
To: "Hal Finney" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: critical bit (5.2.3.1)
Date: Wed, 30 Sep 1998 09:42:50 -0700
Importance: Normal
Sender: [email-masked]

Hal Finney writes:
> Werner Koch, <[email-masked]>, writes:
> > >From section 5.2.3.1:
> >
> If I create a signature and set the critical bit on an unhashed packet,
> it means that I want you to understand that packet before you accept
> the signature.  So in this case it is my desire that the signature should
> be invalidated if you don't understand the packet.
>
> If an attacker tries to make a signature invalid by adding an unhashed
> packet with the critical bit set, he could have just as easily modified
> some part of the hashed region, or the signature itself.

I agree with this; however, the converse is a problem. If you make an
unhashed packet critical, an attacker can turn the critical bit off without
invalidating the security; this means that critical bits cannot be relied
upon, and as such should not be part of the signature validation procedure.
I would suggest that critical bits only be supported in hashed subpackets.

 - Tim

Date: Wed, 30 Sep 1998 09:39:38 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: critical bit (5.2.3.1)
Sender: [email-masked]

Even though that particular attack may not be a problem, you are right
that it seems illogical to set the critical bit on an unhashed packet.

Making a packet unhashed is saying that there are no security implications
if the packet is altered or removed.  But setting the critical bit means
that there are security implications if the packet is not understood.
Doing both at once means that you don't care if the packet is altered or
removed, but that it must be understood, which doesn't make much sense.

Hal

Date: Wed, 30 Sep 1998 17:52:27 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: critical bit (5.2.3.1)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hal Finney <[email-masked]> writes:

> If an attacker tries to make a signature invalid by adding an unhashed
> packet with the critical bit set, he could have just as easily modified
> some part of the hashed region, or the signature itself.

I thought about it while working on the import stuff; but you are
right it doesn't matter whether the critical bit is in the hashed or
unhashed region.  

Thanks,

  Werner

Date: Wed, 30 Sep 1998 07:48:06 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: critical bit (5.2.3.1)
Sender: [email-masked]

> easy to invalidate a signature by setting the critical bit in a

I'm not sure what issue you are concerned with;

If I create a signature and set the critical bit on an unhashed packet,
it means that I want you to understand that packet before you accept
the signature.  So in this case it is my desire that the signature should
be invalidated if you don't understand the packet.

If an attacker tries to make a signature invalid by adding an unhashed
packet with the critical bit set, he could have just as easily modified
some part of the hashed region, or the signature itself.

Hal

To: [email-masked]
Subject: Re: error in draft 07, section 5.1 ?
Date: Wed, 30 Sep 1998 10:13:33 +0200
From: Ian BROWN <[email-masked]>
Sender: [email-masked]

>Yes, you appear to be correct.  The algorithm identifier is not included
>in the checksum.

Did nobody notice the three messages that Ulf Moller and I sent about this 
starting more than a month ago?

Ian.

Date: Wed, 30 Sep 1998 10:38:36 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: critical bit (5.2.3.1)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

  Werner 

Date: Tue, 29 Sep 1998 14:42:52 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: error in draft 07, section 5.1 ?
Sender: [email-masked]

Werner Koch, <[email-masked]>, writes:
> >From section 5.1:
>
> > algorithm used to encrypt the following Symmetrically Encrypted Data
> > Packet.  Then a two-octet checksum is appended which is equal to the
> > sum of the preceding octets, including the algorithm identifier and
> > session key, modulo 65536.   algorithm used to encrypt the following
>
> I don't see that the algorithm identifier is included in the checksum.
> Both, gnupg and opgpg 0.99x, don't include the algorithm in the
> checksum and interoperation with pgp 5.x is okay.

Yes, you appear to be correct.  The algorithm identifier is not included
in the checksum.

Hal Finney

Date: Tue, 29 Sep 1998 21:07:55 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: error in draft 07, section 5.1 ?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

While checking GNUPG's OpenPGP compliance I detected this:

>From section 5.1:

> algorithm used to encrypt the following Symmetrically Encrypted Data
> Packet.  Then a two-octet checksum is appended which is equal to the
> sum of the preceding octets, including the algorithm identifier and
> session key, modulo 65536.   algorithm used to encrypt the following

I don't see that the algorithm identifier is included in the checksum.
Both, gnupg and opgpg 0.99x, don't include the algorithm in the
checksum and interoperation with pgp 5.x is okay.

Maybe I'm blind, but ...

BTW, as far as I can see, gnupg 0.4.1 (will be released soon) is in
compliance with the draft.

  Werner

Date: Tue, 29 Sep 1998 08:56:36 +0100
To: Adam Back <[email-masked]>
From: William Ottaway <[email-masked]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822  headers in S/MIME or PGP/MIME messages)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 18:48 28/09/98 +0100, Adam Back wrote:
>
>Bill Ottaway writes:
>> However, organisations want to control the release of messages from their
>> employees.  They want to make sure outgoing messagers do not contain any
>> sensitive information or viruses. If the sender encrypts his mail
>> using the recipients key the organisation can not perform any of
>> these checks.
>
>Snooping outgoing email for sensitive information isn't a general
>commercial requirement.
>
>It is predominantly a government / signals intelligence special
>interest goal.
>
>UK's DERA (Defense Research Agency) / GCHQ designed the CASM protocol
>to allow snooping on sent and received email.
>
>CASM is partly based on server encryption.  Bill works for DERA
>(dera.gov.uk), so I am wondering if he is thinking of CASM in his
>comments, in that some of his arguments are couched in terms of a
>desire for mail snooping, while others were discussing server
>decryption purely in terms of ease of deployment, and adding blanket
>super-encryption, security and forward-secrecy for email that would
>otherwise not be encrypted.
>

No I wasn't thinking of CASM. I was just making a point that certain
organisations will want to be able to check their employees email for one
reason or another, this is not a military/government only issue.

Once companies start signing outgoing mail, which they will do, they are
taking some responsibility for the contents of that message. If that
message contained a virus then they could be sued for damage caused by that
virus. Signing is also a powerful mechanism which can be used in financial
transactions. Joe Blogs might not have the authority to perform financial
transactions, but a rubber seal from his organisation does carry the this
authority. This sort of transaction may need to be encrypted so that other
commercial organisations do not get wind of what you are up to. 

Yes the military and government have sensitive information which they do
not want to be mailed out of their organisations, but so do commercial
organisations (e.g. trade secrets, research, etc). This may not be a
requirement of all commercial companies but it still needs to be taken into
account when considering signing and encrypting messages. 

I would expect all large organisations, military, government or commercial
to require the ability to check employees email and to do
encryption/signing by the organisation.

>(CASM includes a form of GACK involving recomputing seed material, for
>details see:
>
>	http://www.opengroup.org/public/tech/security/pki/cki/
>
>)
>
>(As an aside, IMO, CASM is not a very elegant protocol: it has many
>online messages, uses public key crypto where symmetric could acheive
>the same effect with equal security, and has a centralised risk of the
>seed material of the root node of the hierarchy being compromised.)
>
>Shared keys or server encryption copes with multiple recipients
>needing to be able to decrypt messages (the `sales team' scenario).
>
>Server encryption is useful to augment personal key based security,
>and/or to speed deployment of "some" encryption even if not at first
>cut personal key based.
>
>I agree with Bill's comments about reduced PKI overhead of server
>based crypto, and his ease of deployment comments.
>
>Adam

Bill.

Date: Mon, 28 Sep 1998 18:48:06 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Sender: [email-masked]

Bill Ottaway writes:
> However, organisations want to control the release of messages from their
> employees.  They want to make sure outgoing messagers do not contain any
> sensitive information or viruses. If the sender encrypts his mail
> using the recipients key the organisation can not perform any of
> these checks.

Snooping outgoing email for sensitive information isn't a general
commercial requirement.

It is predominantly a government / signals intelligence special
interest goal.

UK's DERA (Defense Research Agency) / GCHQ designed the CASM protocol
to allow snooping on sent and received email.

CASM is partly based on server encryption.  Bill works for DERA
(dera.gov.uk), so I am wondering if he is thinking of CASM in his
comments, in that some of his arguments are couched in terms of a
desire for mail snooping, while others were discussing server
decryption purely in terms of ease of deployment, and adding blanket
super-encryption, security and forward-secrecy for email that would
otherwise not be encrypted.

(CASM includes a form of GACK involving recomputing seed material, for
details see:

	http://www.opengroup.org/public/tech/security/pki/cki/

)

(As an aside, IMO, CASM is not a very elegant protocol: it has many
online messages, uses public key crypto where symmetric could acheive
the same effect with equal security, and has a centralised risk of the
seed material of the root node of the hierarchy being compromised.)

Shared keys or server encryption copes with multiple recipients
needing to be able to decrypt messages (the `sales team' scenario).

Server encryption is useful to augment personal key based security,
and/or to speed deployment of "some" encryption even if not at first
cut personal key based.

I agree with Bill's comments about reduced PKI overhead of server
based crypto, and his ease of deployment comments.

Adam

Date: Mon, 28 Sep 1998 17:00:48 +0100
To: "William H. Geiger III" <[email-masked]>, "Blake Ramsdell" <[email-masked]>
From: William Ottaway <[email-masked]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Cc: "Steve Hole" <[email-masked]>, "Ned Freed" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 16:00 25/09/98 -0500, William H. Geiger III wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>In <[email-masked]>, on 09/25/98 
>   at 01:47 PM, "Blake Ramsdell" <[email-masked]> said:
>
>>> -----Original Message-----
>>> From: William H. Geiger III [mailto:[email-masked]]
>>> Sent: Friday, September 25, 1998 1:22 PM
>>> To: Steve Hole
>>> Cc: Ned Freed; [email-masked]; [email-masked]
>>> Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
>>> 
>>> In <[email-masked]>, on 09/18/98 
>>>    at 10:55 AM, Steve Hole <[email-masked]> said:
>>> 
>>> >Also there has been discussion many times in the past of 
>>> having "proxy 
>>> >security handling" for IMAP servers where the IMAP server handles
>>> >decoding encrypted messages on behalf of the client and sending the
>>> >decoded content over an encrypted data connection to the 
>>> client.   Note
>>> >that this is not a  real situation now, but there are lots 
>>> of reasons for
>>> >people to want this  behaviour in the future and it continues to be
>>> >discussed.
>>> 
>>> IMHO this is *not* a good idea.
>>> 
>>> The purpose of using end-to-end encryption is to avoid the 
>>> use of unknown
>>> 3 party systems to relay encrypted data. Decrypting on the server then
>>> re-encrypting via different means devalues the original encryption and
>>> brings unnecessary exposure of the raw data. It would also 
>>> require that
>>> the decryption keys of the recipient be stored on the server adding an
>>> added level of insecurity.
>
>>The originator can encrypt for the server, which will then decrypt the
>>message and send it on to the recipient.  The server does not need to
>>have the recipient's private key -- in fact, the recipient may not have a
>>keypair at all (only the server).  The value of the original encryption
>>is to keep things protected at the message level over the public
>>Internet, and then place the plaintext on the local trusted network. 
>>This allows for organizations to implement message-level security without
>>having to put cryptography on the individual desktops.
>
>I don't like it. It goes against the concepts of end-to-end encryption. If
>I want to send an encrypted message to someone, I want *only* that
>recipient to be able to read that message, not someone down in MIS, not
>some mail clerk, or god knows who else that has access to the local
>network. This is the whole point of end-to-end encryption, I don't have to
>"trust" any network security, all I have to trust is my local security and
>my recipient's local security. While not putting encryption on the users
>desktop may be a selling point to the pointy haired bosses it is a
>downgrade of the encryption protocols and not a direction I would
>recommend.
>
>>> While I have played with "proxy security handling" in the 
>>> past it has been
>>> for out-bound encryption, in-bound signature verification, and policy
>>> enforcement. In-bound decryption & out-bound signing should 
>>> never be done
>>> by anyone but the owner of the private keys.
>
>>The server can have private keys also, and the semantics of the outbound
>>signature is that the server (or organization) signed the message, not
>>the individual.
>
>IMHO this is poor practice. Corporate documents should be signed by the
>author(s) of those documents not some universal company signature. Even
>with corporate entities, one still needs to tie back to individuals in the
>corporation during communications. I may be missing something here, but I
>don't see the value of a generic corporate signature.
>
William,

Have you read draft-ietf-smime-domsec-00.txt?

This contains a section on encryption between servers, and between
individuals and servers. It does not rule out user to user encryption.

I agree with your points on not letting anyone else read your email.
However, organisations want to control the release of messages from their
employees. They want to make sure outgoing messagers do not contain any
sensitive information or viruses. If the sender encrypts his mail using the
recipients key the organisation can not perform any of these checks.

Encrypting and signing using an organisations key rather than an
individuals key reduces the size of the PKI required, and therefore all of
the problems to do with setting up and maintaining a PKI. Plus you are
putting a higher level of credence on the message, its not just coming from
Joe Blogs; its coming from Joe Blogs organisation.

Server to server encryption and signing reduces the cost of buying and
maintaining encryption facilities on the individuals machines. Plus the
burden on the users machine.

You can still tie a message back to the individual by allowing originator
aswell as domain signatures. Infact I recommend the message being signed by
the originator. This gives the organisation the ability to check the
document has not changed, to control who can release messages and a means
of repudination. 

Bill.
________________________________________________________________
William Ottaway,
L323,                        Tel: +44 (0) 1684 894079
DERA Malvern,                Fax: +44 (0) 1684 896113
St. Andrews Road,            email: [email-masked]
Malvern,
Worcs,
WR14 3PS

Date: Mon, 28 Sep 1998 13:23:23 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Sender: [email-masked]

William Geiger writes:
> I don't like it. It goes against the concepts of end-to-end
> encryption. If I want to send an encrypted message to someone, I
> want *only* that recipient to be able to read that message, not
> someone down in MIS, not some mail clerk, or god knows who else that
> has access to the local network.
 
This is the way that I think would make sense to set this up.  (I
spent some specing a system to do this for corporate environments).
Bear in mind there is a trade off with some brackets of users: letting
them manage their own keys may be worse than having a machine locked
up in a machine room decrypting for them.  Certainly having a machine
in a machine room AND them both decrypting (super-encrypted traffic)
is more secur than them decrypting on their own.

You have your normal PGP encrypted messages for individuals.  You also
have a outgoing auto-encrypter and an incoming auto-decrypter.

Auto-encrypter:

If the recipient has an individual key (the email adddress is an
individual address) the auto-encrypter encrypts for that individual if
the message is not already encrypted.  You optionally super-encrypt
with the auto-decrypter's public key.

If the recipient does not have an individual key, the message is
encrypted with the recipient's system's auto-decryptor public key.

Auto-decrypter:

Decrypt anything which is decryptable with the auto-decrypter's
private key.

This then is strictly more secure than just PGP on it's own because it
adds security for:

- people who forget to encrypt
- people who don't want to learn how to use encryption
- all messages between sites having the auto-decrypt/auto-encrypt ability

For bonus points you observe that the traffic between the
auto-decrypt/auto-encrypt could just as well be encrypted with forward
secrecy.

You might also observe that installing IPSEC on sending and receiving
mail hub would achieve exactly the same thing (including forward
secrecy).

Mark Grant:
> And as I've mentioned before, this system solves most if not all of the
> problems that CMR claims to solve, without the new problems it creates.

Agree strongly!

Adam

Date: Mon, 28 Sep 1998 04:07:25 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Sender: [email-masked]

William H. Geiger III [[email-masked]] wrote:
>I don't like it. It goes against the concepts of end-to-end encryption. If
>I want to send an encrypted message to someone, I want *only* that
>recipient to be able to read that message, not someone down in MIS, not
>some mail clerk, or god knows who else that has access to the local
>network. 

I think there's a definite use in corporate-land; just as when I submit an
order to a web-server I use a corporate ordering encryption key, there's
no reason why when I send an order in by email I would use a personal key
rather than a group key. Just as the web-server decrypts the order and
probably stores it in a plaintext file somewhere, the mail server can 
decrypt the order and pass it in plaintext to the first available clerk.

In some cases I want to send mail to a particular person in the company,
but in most cases I just want to send it to a particular department, who
would have to either share a key or have a decryption server. As long as
PGP warns that it's a shared/server-decrypted key (there was talk of 
creating an Open-PGP flag to indicate this, but I don't know whether it
happened) I don't see a problem.

And as I've mentioned before, this system solves most if not all of the
problems that CMR claims to solve, without the new problems it creates.

    Mark

Date: Fri, 25 Sep 1998 14:22:57 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
To: "William H. Geiger III" <[email-masked]>
Cc: Ned Freed <[email-masked]>, Graham Klyne <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > I don't know about message/http, but I suspect it would need its own
> > rules. And it isn't clear this issue exists for HTTP anyhow, or that if
> > it does it should be solved this way.

> I am not aware of a message/http. It is my understanding that if you have
> an e-mail message attachment (with headers) that you should use the
> message/rfc822 and then text/http as a MIME part of the attached message
> (with multipart/mixed or multipart/alternative in the message header).

The concept of "message" is a lot more general than e-mail these days. As
are the uses MIME is put to.

Message/http is the media type for an HTTP message. See RFC2068 for details.

> In general message/rfc822 is to be used to signify that a MIME part is a
> message with headers and that the user should reference the header of that
> message for it's context.

An email message, yes. A message in a more general sense, no.

				Ned

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 25 Sep 1998 16:00:40 -0500
To: "Blake Ramsdell" <[email-masked]>
Cc: "Steve Hole" <[email-masked]>, "Ned Freed" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Sender: [email-masked]

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

In <[email-masked]>, on 09/25/98 
   at 01:47 PM, "Blake Ramsdell" <[email-masked]> said:

>> -----Original Message-----
>> From: William H. Geiger III [mailto:[email-masked]]
>> Sent: Friday, September 25, 1998 1:22 PM
>> To: Steve Hole
>> Cc: Ned Freed; [email-masked]; [email-masked]
>> Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
>> 
>> In <[email-masked]>, on 09/18/98 
>>    at 10:55 AM, Steve Hole <[email-masked]> said:
>> 
>> >Also there has been discussion many times in the past of 
>> having "proxy 
>> >security handling" for IMAP servers where the IMAP server handles
>> >decoding encrypted messages on behalf of the client and sending the
>> >decoded content over an encrypted data connection to the 
>> client.   Note
>> >that this is not a  real situation now, but there are lots 
>> of reasons for
>> >people to want this  behaviour in the future and it continues to be
>> >discussed.
>> 
>> IMHO this is *not* a good idea.
>> 
>> The purpose of using end-to-end encryption is to avoid the 
>> use of unknown
>> 3 party systems to relay encrypted data. Decrypting on the server then
>> re-encrypting via different means devalues the original encryption and
>> brings unnecessary exposure of the raw data. It would also 
>> require that
>> the decryption keys of the recipient be stored on the server adding an
>> added level of insecurity.

>The originator can encrypt for the server, which will then decrypt the
>message and send it on to the recipient.  The server does not need to
>have the recipient's private key -- in fact, the recipient may not have a
>keypair at all (only the server).  The value of the original encryption
>is to keep things protected at the message level over the public
>Internet, and then place the plaintext on the local trusted network. 
>This allows for organizations to implement message-level security without
>having to put cryptography on the individual desktops.

I don't like it. It goes against the concepts of end-to-end encryption. If
I want to send an encrypted message to someone, I want *only* that
recipient to be able to read that message, not someone down in MIS, not
some mail clerk, or god knows who else that has access to the local
network. This is the whole point of end-to-end encryption, I don't have to
"trust" any network security, all I have to trust is my local security and
my recipient's local security. While not putting encryption on the users
desktop may be a selling point to the pointy haired bosses it is a
downgrade of the encryption protocols and not a direction I would
recommend.

>> While I have played with "proxy security handling" in the 
>> past it has been
>> for out-bound encryption, in-bound signature verification, and policy
>> enforcement. In-bound decryption & out-bound signing should 
>> never be done
>> by anyone but the owner of the private keys.

>The server can have private keys also, and the semantics of the outbound
>signature is that the server (or organization) signed the message, not
>the individual.

IMHO this is poor practice. Corporate documents should be signed by the
author(s) of those documents not some universal company signature. Even
with corporate entities, one still needs to tie back to individuals in the
corporation during communications. I may be missing something here, but I
don't see the value of a generic corporate signature.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Windows?  Homey don't play that!

From: "Blake Ramsdell" <[email-masked]>
To: "'William H. Geiger III'" <[email-masked]>, "Steve Hole" <[email-masked]>
cc: "Ned Freed" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Date: Fri, 25 Sep 1998 13:47:39 -0700
Sender: [email-masked]

> -----Original Message-----
> From: William H. Geiger III [mailto:[email-masked]]
> Sent: Friday, September 25, 1998 1:22 PM
> To: Steve Hole
> Cc: Ned Freed; [email-masked]; [email-masked]
> Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
> 
> In <[email-masked]>, on 09/18/98 
>    at 10:55 AM, Steve Hole <[email-masked]> said:
> 
> >Also there has been discussion many times in the past of 
> having "proxy 
> >security handling" for IMAP servers where the IMAP server handles
> >decoding encrypted messages on behalf of the client and sending the
> >decoded content over an encrypted data connection to the 
> client.   Note
> >that this is not a  real situation now, but there are lots 
> of reasons for
> >people to want this  behaviour in the future and it continues to be
> >discussed.
> 
> IMHO this is *not* a good idea.
> 
> The purpose of using end-to-end encryption is to avoid the 
> use of unknown
> 3 party systems to relay encrypted data. Decrypting on the server then
> re-encrypting via different means devalues the original encryption and
> brings unnecessary exposure of the raw data. It would also 
> require that
> the decryption keys of the recipient be stored on the server adding an
> added level of insecurity.

The originator can encrypt for the server, which will then decrypt the
message and send it on to the recipient.  The server does not need to
have the recipient's private key -- in fact, the recipient may not have
a keypair at all (only the server).  The value of the original
encryption is to keep things protected at the message level over the
public Internet, and then place the plaintext on the local trusted
network.  This allows for organizations to implement message-level
security without having to put cryptography on the individual desktops.

> While I have played with "proxy security handling" in the 
> past it has been
> for out-bound encryption, in-bound signature verification, and policy
> enforcement. In-bound decryption & out-bound signing should 
> never be done
> by anyone but the owner of the private keys.

The server can have private keys also, and the semantics of the outbound
signature is that the server (or organization) signed the message, not
the individual.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 25 Sep 1998 15:21:52 -0500
To: Steve Hole <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Sender: [email-masked]

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

In <[email-masked]>, on 09/18/98 
   at 10:55 AM, Steve Hole <[email-masked]> said:

>Also there has been discussion many times in the past of having "proxy 
>security handling" for IMAP servers where the IMAP server handles
>decoding encrypted messages on behalf of the client and sending the
>decoded content over an encrypted data connection to the client.   Note
>that this is not a  real situation now, but there are lots of reasons for
>people to want this  behaviour in the future and it continues to be
>discussed.

IMHO this is *not* a good idea.

The purpose of using end-to-end encryption is to avoid the use of unknown
3 party systems to relay encrypted data. Decrypting on the server then
re-encrypting via different means devalues the original encryption and
brings unnecessary exposure of the raw data. It would also require that
the decryption keys of the recipient be stored on the server adding an
added level of insecurity.

While I have played with "proxy security handling" in the past it has been
for out-bound encryption, in-bound signature verification, and policy
enforcement. In-bound decryption & out-bound signing should never be done
by anyone but the owner of the private keys.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: The best way to accelerate Windows is at escape velocity.

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 25 Sep 1998 15:10:52 -0500
To: Ned Freed <[email-masked]>
Cc: Graham Klyne <[email-masked]>, Ned Freed <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Sender: [email-masked]

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

In <[email-masked]>, on 09/24/98 
   at 02:18 AM, Ned Freed <[email-masked]> said:

>I don't know about message/http, but I suspect it would need its own
>rules. And it isn't clear this issue exists for HTTP anyhow, or that if
>it does it should be solved this way.

I am not aware of a message/http. It is my understanding that if you have
an e-mail message attachment (with headers) that you should use the
message/rfc822 and then text/http as a MIME part of the attached message
(with multipart/mixed or multipart/alternative in the message header).

In general message/rfc822 is to be used to signify that a MIME part is a
message with headers and that the user should reference the header of that
message for it's context.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: My best view from a Window was through OS/2.

Date: Thu, 24 Sep 1998 00:18:57 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
To: Graham Klyne <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> But, I think there is still a question whether this "structural handling"
> information is specific to *just* RFC822.  The premise of my suggestion was
> that the structural handling was more widely applicable.  I am toying with
> a view that the handling may be appropriate to 'message/...' types in general.

It certainly doesn't apply to the subtypes delivery-status or
disposition-notification. This alone makes calling it a general message type
parameter inappropriate. It would at most be a parameter specific message
subtypes could call on if needed.

It can apply to message/external-body, although it only applies indirectly
when message/external-body references a message/rfc822 object.

Message/partial already has well defined structural considerations (indeed,
these rules should serve as a starting point for defining how to recombine
message/rfc822 objects) and needs no such parameter. I actually would have
suggested using a single part message/partial for this were it not for my
belief that the reassembly rules are likely to be different in some ways.

The type message/news should never have been defined -- message/rfc822 was
designed to accomodate news messages despite its name -- and in practice is not
used. 

I don't know about message/http, but I suspect it would need its own rules. And
it isn't clear this issue exists for HTTP anyhow, or that if it does it should
be solved this way.

And that's the entire list of message types.

As a practical matter this sort of structural concern only exists when there's
a set of "outer" headers which are exposed to transport manipulation and hence
cannot be secured by putting them inside of a security enclosure. Now, this
doesn't mean such things cannot appear at an inner level -- this will happen
when someone wants to include an entire message built this way with its
security wrapper intact within another message.

But this does restrict the reasons for using this scheme.  We only have two
outer message types which transports manipulate at present: message/rfc822
(which also covers News) and message/http. I don't want to get into
message/http at the present time. And that leaves message/rfc822.

> A recent discusion I had concerned the actual handling differences between
> 'application/...' and 'message/...' (with reference in part to proposing
> 'application/MIME' vs 'message/MIME').  One view was that 'message/...'
> indicates handling that is expected to be performed by a message handling
> agent, where 'application/...' suggests some external program;  this seems
> to be consistent with the idea that MIME content-types are used for
> dispatching to a handling module or application.

This is a reasonable view. But it doesn't mean that a message/mime object,
should one be defined, would benefit from this sort of structural handling. If
you want to secure such an object all you have to do is put the whole kit and
kaboodle inside of the security enclosure. I see no justifcation for exposing
part of it outside and having to recombine later. (Yes, I realize that people
have on occasion argued that there's value in confidentiality services that
expose, say, the content-type of of the secured material. However, I remain to
be convinced that this is a good idea, let alone that it should be accomplished
by something similar to this.)

> I feel I may be going over some old ground here, and don't wish to restart
> an old debate, but I would be interested in your view.

See above. Also note that if I'm wrong and there's value in using this
mechanism elsewhere, its definition can easily be borrowed in the definition
of another type or subtype at a later date.

				Ned

Date: Wed, 23 Sep 1998 10:18:05 +0100
To: Ned Freed <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 09:32 22/09/98 -0700, Ned Freed wrote:
>> > I personally favor a message/rfc822 parameter, but I can also see a
case for
>> > putting it elsewhere. What do other people think? [...]
>
[...]
>I considered a content-disposition value, but quickly rejected it. My reasons
>include:
>
>(1) This usage is specific to message/rfc822; it doesn't make sense on other
>    content types. Dispositions are supposed to apply regardless of type, and
>    definitely shouldn't be highly type-specific.
>(2) Applications may want to specify a disposition for a message independent
>    of security handling. This results in the one field being used for two
>    things.
>(3) This isn't a disposition per se; it is structural handling information.

I agree -- especially your reason 3 which I realized after my earlier posting.

But, I think there is still a question whether this "structural handling"
information is specific to *just* RFC822.  The premise of my suggestion was
that the structural handling was more widely applicable.  I am toying with
a view that the handling may be appropriate to 'message/...' types in general.

A recent discusion I had concerned the actual handling differences between
'application/...' and 'message/...' (with reference in part to proposing
'application/MIME' vs 'message/MIME').  One view was that 'message/...'
indicates handling that is expected to be performed by a message handling
agent, where 'application/...' suggests some external program;  this seems
to be consistent with the idea that MIME content-types are used for
dispatching to a handling module or application.

I feel I may be going over some old ground here, and don't wish to restart
an old debate, but I would be interested in your view.

#g

------------
Graham Klyne
([email-masked])

Date: Tue, 22 Sep 1998 09:32:09 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
To: Graham Klyne <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > I personally favor a message/rfc822 parameter, but I can also see a case for
> > putting it elsewhere. What do other people think? If there seems to be
> > consensus that this needs to be on message/rfc822, I'd be happy to write
> > a short draft defining such a parameter.

> It sounds as if this might be a role for content-disposition.  In a
> non-RFC822 environment, one might wish to apply the "promotion" principle
> for content types other than message/rfc822, and to encapsulations other
> than signature/encryption.

I considered a content-disposition value, but quickly rejected it. My reasons
include:

(1) This usage is specific to message/rfc822; it doesn't make sense on other
    content types. Dispositions are supposed to apply regardless of type, and
    definitely shouldn't be highly type-specific.
(2) Applications may want to specify a disposition for a message independent
    of security handling. This results in the one field being used for two
    things.
(3) This isn't a disposition per se; it is structural handling information.

				Ned

Date: Tue, 22 Sep 1998 11:13:53 +0100
To: Ned Freed <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 15:47 17/09/98 -0700, Ned Freed wrote:
>> I'd like to see a convention established for interpreting the
>> message/rfc822 type in this way, possibly when accompanied by some
>> other syntax.
>
>I agree that this would be useful functionality -- I've suggested adding
>it several times in the past, but was never able to get much support
>for it.
>
>Its clear that this indicator has to be on the "inside", since you want the
>signature to be able to cover it. This then begs the question of whether
>it should be an attribute of the signature/encryption facility or of the 
>MIME message/rfc822 content.
>
>I personally favor a message/rfc822 parameter, but I can also see a case for
>putting it elsewhere. What do other people think? If there seems to be
>consensus that this needs to be on message/rfc822, I'd be happy to write
>a short draft defining such a parameter.

It sounds as if this might be a role for content-disposition.  In a
non-RFC822 environment, one might wish to apply the "promotion" principle
for content types other than message/rfc822, and to encapsulations other
than signature/encryption.

#g

------------
Graham Klyne
([email-masked])

From: Steve Hole <[email-masked]>
Date: Fri, 18 Sep 1998 09:55:19 -0600
To: Ned Freed <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [email-masked], [email-masked]
Sender: [email-masked]

--Part9809180955.F
Content-Type: Text/PLAIN; CHARSET=US-ASCII

On Thu, 17 Sep 1998 15:47:36 -0700 (PDT) Ned Freed <[email-masked]>
wrote:

> I personally favor a message/rfc822 parameter, but I can also see a case for
> putting it elsewhere. What do other people think? If there seems to be
> consensus that this needs to be on message/rfc822, I'd be happy to write
> a short draft defining such a parameter.

So do I.   There are some reasonably complex interplays between cached and 
displayed structures in the presence of security - especially in an IMAP4 mail 
client.   Clients that cache MIME structures will often do things like cache
overlays for security multiparts so that their UI code doesn't have to know
anything about security -- that is all handled at the MIME abstraction level.
Also there has been discussion many times in the past of having "proxy 
security handling" for IMAP servers where the IMAP server handles decoding
encrypted messages on behalf of the client and sending the decoded content
over an encrypted data connection to the client.   Note that this is not a 
real situation now, but there are lots of reasons for people to want this 
behaviour in the future and it continues to be discussed.

The message/rfc822 solution would work transparently in the cases described 
above.   If the parameter is attached to the security multiparts then it is
possible that it will be occluded or lost by an MUA in the act of removing 
the security.   Putting it at the message/rfc822 level means that it will
always be exposed to UI code and the UI can decide how to "cook" the display
to show the right thing. 

Cheers. 

---  
Steve Hole                           
The Esys Corporation
Mailto:[email-masked]  
Phone:403-424-4922

--Part9809180955.F
Content-Type: Application/pgp-signature

--Part9809180955.F--

Date: Fri, 18 Sep 1998 13:24:02 +0100
To: [email-masked], [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Sender: [email-masked]

In article <[email-masked]>, Ned Freed
<[email-masked]> writes
>> (Apologies if this has been done to death in the past - I can imagine
>> Ned sighing about protracted discussions prior to RFC1847 - but I
>> couldn't find any discussion in the archives)
>
>> RFC2311 (SMIME) and RFC1847 (upon which PGP/MIME has been based) only
>> allow MIME headers to be protected by the encryption process. Was there
>> any discussion during the preparation of RFC1847 about the possibility /
>> desirability / feasibility of allowing general RFC822 headers to be
>> included in the encrypted part of the message?
>
>There were extensive discussions of this. I probably have several hundred
>messages archived on this topic, and there were also WG discussions and several
>private meetings where the design team covered this area exhaustively.
>

Thought as much :-)

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

I was just thinking of encryption, but of course a scheme that covers
signing headers as well as encrypting them is so much the better.

>
>> Could (and should) any replacements for RFC2015 and RFC2311 be amended
>> to allow RFC822 headers to be sent encrypted, and for the decryption
>> process to swap any encrypted headers found with the corresponding
>> headers in the actual message?
>
>There is no need to do this. All you need to do is use MIME encapsulation
>to put the real headers into the body of the message.
>

My problem with that was that the intent of encapsulation would not be
clear. However, putting a parameter on the message/rfc822 to make it
clear seems to solve the problem completely.

Later, you wrote:

>Its clear that this indicator has to be on the "inside", since you want the
>signature to be able to cover it. This then begs the question of whether
>it should be an attribute of the signature/encryption facility or of the 
>MIME message/rfc822 content.

Putting the parameter at the encryption header level announces that
there are hidden headers that will be substituted, though maybe that's
too minor a security breach to worry about.

A parameter at the message/rfc822 header level would in one extension
cover signed, encrypted, encrypted-then-signed and encrypted-and-signed
messages, and would even allow messages to be resent without using
Resent- headers if anyone has a use for that!

>
>-- I've suggested adding
>it several times in the past, but was never able to get much support
>for it.
>

Hopefully this thread will have demonstrated sufficient support.

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

Date: Thu, 17 Sep 1998 22:55:50 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
To: "John  W. Noerenberg" <[email-masked]>
Cc: Ned Freed <[email-masked]>, Hal Finney <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > Its clear that this indicator has to be on the "inside", since you want the
> > signature to be able to cover it. This then begs the question of whether
> > it should be an attribute of the signature/encryption facility or of the
> > MIME message/rfc822 content.

> Putting the indicator the header exposes information about the message --
> the decrypted contents of the message is supposed to replace the headers of
> the message.  Keeping it inside doesn't reveal this.

The header indicator would be on the _inner_ header, not the outer one.
This is no more revealing than anything else that's "inside".

> > I personally favor a message/rfc822 parameter, but I can also see a case for
> > putting it elsewhere. What do other people think? If there seems to be
> > consensus that this needs to be on message/rfc822, I'd be happy to write
> > a short draft defining such a parameter.

> Maybe only the truly paranoid care about this, but it does violate a
> security principle.  Putting it inside the ciphertext probably complicates
> the MUA's job, but I don't think it's a particularly daunting complication.

I'm talking about putting it inside the ciphertext (assuming encyption
is used, of course).

Amusingly enough, we've had objections in the past from security experts saying
that putting the MIME labelling of the encrypted content inside the encryption
is a Bad Thing. (Of course this didn't result in any changes.) So much for
agreement in principle ;-)

				Ned

From: "Tom Phinney" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Date: Thu, 17 Sep 1998 22:33:07 -0700
Sender: [email-masked]

From: [email-masked]

> > Could (and should) any replacements for RFC2015 and RFC2311 be
amended
> > to allow RFC822 headers to be sent encrypted, and for the
decryption
> > process to swap any encrypted headers found with the corresponding
> > headers in the actual message?
>
> To my best knowledge, there is a non-official scheme to do this. Here
> is an example:
>
> X-PGP-Sig: 2.6.3ia Subject,From,X-Mailer
>        
iQCVAwUBM84wngE7m572a9utAQETEgQAwcL38QVdZbkHuW4Mblmje17deuI85R1j
4yGiDlb1enRDSUyGiLCmk8YphNDiLdKKlMV3Z0opzREUW9Q+sb8fr5s1QXMJhvXs
7hi7s4+V00rjgbqbqXVNiajKiKfVxd7JTRfe0UIZuOljnURP1ZCMlSRD1rDoCEAg
>         1vunQv6QYj4=
>         =hvn0
>
> This is a header field to be stored in a header, mixed with fields to
> be proteced such as Subject, From, and X-Mailer.
>
> If you are interested, I will ack the author to explain his
> experiences.

Of course, there's already a mature technology which uses PGP to 
encapsulate message headers and contents, which replace the original 
message headers and contents after decryption.  It's used in the Type 1

Cypherpunk remailers.  :-)

I'm not proposing that you should use this; it doesn't seem
appropriate.  
But it is worth studying as a reference technology which achieves the 
privacy goals being discussed her.

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Fri, 18 Sep 1998 13:00:21 +0900
Lines: 28
Sender: [email-masked]

Ian,

From: Ian Bell <[email-masked]>
Subject: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Date: Thu, 17 Sep 1998 11:02:49 +0100

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

To my best knowledge, there is a non-official scheme to do this. Here
is an example:

X-PGP-Sig: 2.6.3ia Subject,From,X-Mailer
        iQCVAwUBM84wngE7m572a9utAQETEgQAwcL38QVdZbkHuW4Mblmje17deuI85R1j
        4yGiDlb1enRDSUyGiLCmk8YphNDiLdKKlMV3Z0opzREUW9Q+sb8fr5s1QXMJhvXs
        7hi7s4+V00rjgbqbqXVNiajKiKfVxd7JTRfe0UIZuOljnURP1ZCMlSRD1rDoCEAg
        1vunQv6QYj4=
        =hvn0

This is a header field to be stored in a header, mixed with fields to
be proteced such as Subject, From, and X-Mailer.

If you are interested, I will ack the author to explain his
experiences.

--Kazu

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 17 Sep 1998 18:51:45 -0700
Comments: In reply to "John  W. Noerenberg" <[email-masked]> "Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages" (Sep 17,  5:20pm)
To: "John  W. Noerenberg" <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On Sep 17,  5:20pm, John  W. Noerenberg wrote:
} Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
}
} At 3:47 PM -0700 9/17/98, Ned Freed wrote:
} >Its clear that this indicator has to be on the "inside", since you want the
} >signature to be able to cover it. This then begs the question of whether
} >it should be an attribute of the signature/encryption facility or of the
} >MIME message/rfc822 content.
} 
} Putting the indicator the header exposes information about the message -- 
} the decrypted contents of the message is supposed to replace the headers of 
} the message.  Keeping it inside doesn't reveal this.

I think you misunderstand, John.  I believe the suggested format is for
the outer message to specify an encrypted Content-Type, and then for the
encrypted content to be a message/rfc822 with a parameter specifying that
its headers should replace the enclosing message's headers only after the
inner message is successfully decrypted.

This hides the parameter (indeed, it hides the entire nested message/rfc822
structure) inside the ciphertext, but allows a sufficiently clever UA to
present the contained message in place of the top-level message.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: Thu, 17 Sep 1998 17:20:09 -0700
To: Ned Freed <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: Hal Finney <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 3:47 PM -0700 9/17/98, Ned Freed wrote:
>Its clear that this indicator has to be on the "inside", since you want the
>signature to be able to cover it. This then begs the question of whether
>it should be an attribute of the signature/encryption facility or of the
>MIME message/rfc822 content.

Putting the indicator the header exposes information about the message -- 
the decrypted contents of the message is supposed to replace the headers of 
the message.  Keeping it inside doesn't reveal this.

>I personally favor a message/rfc822 parameter, but I can also see a case for
>putting it elsewhere. What do other people think? If there seems to be
>consensus that this needs to be on message/rfc822, I'd be happy to write
>a short draft defining such a parameter.

Maybe only the truly paranoid care about this, but it does violate a 
security principle.  Putting it inside the ciphertext probably complicates 
the MUA's job, but I don't think it's a particularly daunting complication.

john noerenberg
[email-masked]
  ----------------------------------------------------------------------
  --if we are to be saved, it will not be by Romans but by saints.
  -- Thomas Cahill, "how the Irish Saved Civilization", 1995
  ----------------------------------------------------------------------

Date: Thu, 17 Sep 1998 16:41:48 -0700
To: [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Sender: [email-masked]

At 03:47 PM 9/17/98 -0700, Ned Freed wrote:
>I personally favor a message/rfc822 parameter, but I can also see a case for
>putting it elsewhere. What do other people think? If there seems to be
>consensus that this needs to be on message/rfc822, I'd be happy to write
>a short draft defining such a parameter.

Given that OpenPGP is about to go to IESG last call in days, and S/MIME is
in it's last throes, and that the two groups are sure to do things
differently :-), I think a message/rfc822 parameter would be best.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 17 Sep 1998 16:16:44 -0700
Comments: In reply to Ned Freed <[email-masked]> "Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages" (Sep 17,  3:47pm)
To: Ned Freed <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On Sep 17,  3:47pm, Ned Freed wrote:
> Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
> > I'd like to see a convention established for interpreting the
> > message/rfc822 type in this way, possibly when accompanied by some
> > other syntax.
> 
> I personally favor a message/rfc822 parameter, but I can also see a case for
> putting it elsewhere. What do other people think? If there seems to be
> consensus that this needs to be on message/rfc822, I'd be happy to write
> a short draft defining such a parameter.

I think such a parameter would be useful in other situations besides
signed message content, so I support defining it in message/rfc822 rather
than in the signature.

If you do write a draft, please make mention of the interpretation of
this parameter when the message/rfc822 is included by reference via
message/external-body.

-- 
Bart Schaefer                                                   Zanshin
http://www.well.com/user/barts                   http://www.zanshin.com

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

> I'd like to see a convention established for interpreting the
> message/rfc822 type in this way, possibly when accompanied by some
> other syntax.

I agree that this would be useful functionality -- I've suggested adding
it several times in the past, but was never able to get much support
for it.

Its clear that this indicator has to be on the "inside", since you want the
signature to be able to cover it. This then begs the question of whether
it should be an attribute of the signature/encryption facility or of the 
MIME message/rfc822 content.

I personally favor a message/rfc822 parameter, but I can also see a case for
putting it elsewhere. What do other people think? If there seems to be
consensus that this needs to be on message/rfc822, I'd be happy to write
a short draft defining such a parameter.

				Ned

Date: Thu, 17 Sep 1998 12:14:46 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Sender: [email-masked]

Ian Bell writes:

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

The Subject header would be one which would benefit most from encryption.
Subjects leak information about message contents.  Used carelessly, they
may expose the meaning of the message, or at least indicate which messages
contain sensitive information that might be targetted by an attacker.

However, replacing the Subject header only when the message is stored
for later reference misses another possible benefit.  Many archived
messages are never even referred to again.

What would be even better would be if the user's mail software decrypted
all messages in the incoming mailbox and "promoted" message/rfc822
headers up to the message header level.  Then the encrypted message
subjects could be displayed before the messages are read.  Busy email
users often use Subject headers to prioritize their mail handling.
But to make use of this capability, decrypted Subject headers must be
presented by the mail software beforehand.

I'd like to see a convention established for interpreting the
message/rfc822 type in this way, possibly when accompanied by some
other syntax.

Hal

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sure.

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

See above.

				Ned

Date: Thu, 17 Sep 1998 13:40:49 +0100
To: [email-masked], [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Sender: [email-masked]

In article <[email-masked]>, Lindsay Mathieson
<[email-masked]> writes
>
>>RFC2311 (SMIME) and RFC1847 (upon which PGP/MIME has been based) only
>>allow MIME headers to be protected by the encryption process. Was there
>>any discussion during the preparation of RFC1847 about the possibility
>>/ desirability / feasibility of allowing general RFC822 headers to
>>be included in the encrypted part of the message?
>
>Its quite acceptable to generate your message as a message/rfc822 mime type
>and encrypt the entire body.

I had considered that (and had intended to mention it), but using
message/rfc822 doesn't quite give the same effect. In fact it wouldn't
work at all in the case of the Disposition-Notification-To header unless
the RFCs were modified.

The MIME headers within the encrypted body _replace_ the MIME headers in
the header of the message actually received, whereas the headers within
a message/rfc822 body don't. It would not be clear to the receiving MUA
whether the message/rfc822 were to be regarded as a forwarded message or
to be regarded as the original, fully encrypted, message.

Allowing RFC822 headers to be encrypted alongside the MIME headers would
unambiguously indicate that those headers were intended to be part of
the original message.

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

Date: 17 Sep 1998 22:9:46 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
To: Ian Bell <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

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

Its quite acceptable to generate your message as a message/rfc822 mime type
and encrypt the entire body.
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Vs 2.8 Preview 2, on September 17, 1998, in
Win95 4.0
	http://www.blackpaw.com/

Date: Thu, 17 Sep 1998 11:02:49 +0100
To: [email-masked], [email-masked]
From: Ian Bell <[email-masked]>
Subject: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Sender: [email-masked]

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

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

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

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

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

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

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

Date: Wed, 16 Sep 98 00:21 +0200
From: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
To: [email-masked]
Subject: error in draft 07, section 5.2.1
Organization: HR13
Sender: [email-masked]

|   0x01: Signature of a canonical text document.
|       Typically, this means the signer owns it, created it, or
|       certifies that it has not been modified.  The signature is
|       calculated over the text data with its line endings converted to
|       <CR><LF> and trailing blanks removed.

Trailing blanks are removed _only_ for cleartext signatures, in the
transformation described in section 7.1. Otherwise (for signatures
contained in a PGP message, and for detached signatures) they are part
of the signature.

BTW, there's no proper definition of detached signatures in the draft.
They probably should be mentioned in section 10 because they are used
for PGP/MIME.

To: [email-masked]
Cc: [email-masked]
Subject: Re: the micalg parameter
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Mon, 14 Sep 1998 14:02:22 +0900
Lines: 21
Sender: [email-masked]

From: Thomas Roessler <[email-masked]>
Subject: Re: the micalg parameter
Date: Thu, 10 Sep 1998 11:29:56 +0200

> Now, why do you think that a mis-match being illegal means
> that an implementation can't be robust and ignore the
> parameter in this case?  The behaviour is simply undefined, so 
> the choice is yours - conform to the GIGO principle or try  
> to handle things smoothly.

There is a big difference between undefined and implementation choice.

The former means ambiguous. 

The latter menas, yes, you clearly defined. If we will define its
semantics as implementation choice after discussions, it's fine to me.

Personally, I dislike to define it as implementation choice. This is a
signature service, so I think we should share a single semantics.

--Kazu

To: [email-masked]
Cc: [email-masked]
Subject: Re: Revising RFC 2015
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Mon, 14 Sep 1998 13:54:51 +0900
Lines: 25
Sender: [email-masked]

From: Steve Hole <[email-masked]>
Subject: Re: Revising RFC 2015
Date: Thu, 10 Sep 1998 08:55:35 -0600

> Being one of the very few people that has implemented both PGP/MIME
> and S/MIME into their mail products, I can tell you absolutely that
> the use of Multipart/Encrypted is a MUST.  Especially for IMAP4
> mailers where access to the MIME body structure allows a client to
> do intelligent things with an encrypted body part.  You are simply
> wrong on this count.  I would fight to the death any attempt to
> remove multipart/encrypted from the specification.

I said, "this is just for your information". I didn't propose to
introduce such a drastic change to PGP/MIME.

BTW. I have a couple of questions to you.

(1) Why do you think multipart/encrypted is a MUST? What you do mean
intelligent things? I'm very much curious about them. Could you please
explain more concretely?

(2) S/MIME doesn't use multipart/encrypted. Being one of the few
people, what do you think of it?

--Kazu

Date: Fri, 11 Sep 1998 09:55:58 -0400
From: [email-masked]
To: Thorsten Maly <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: Documentation of PGP 2.6.x and PGP 5.x Keyring File Format
Sender: [email-masked]

On Fri, 11 Sep 1998, Thorsten Maly wrote:

> Does anybody know where I can find documentation/developer notes on the 
> Keyring File Format for PGP 2.6.x or PGP 5.x. This aspect does not seem
> to 
> be covered in the draft, nor could I find any information on the web. 

The overall format is in 11.1:

----------
11. Enhanced Key Formats

11.1. Key Structures

   The format of an OpenPGP V3 key is as follows.  Entries in square
   brackets are optional and ellipses indicate repetition.

           RSA Public Key
              [Revocation Self Signature]
               User ID [Signature ...]
              [User ID [Signature ...] ...]

   Each signature certifies the RSA public key and the preceding user
   ID. The RSA public key can have many user IDs and each user ID can
   have many signatures.

   The format of an OpenPGP V4 key that uses two public keys is similar
   except that the other keys are added to the end as 'subkeys' of the
   primary key.

           Primary-Key
              [Revocation Self Signature]
              [Direct Key Self Signature...]
               User ID [Signature ...]
              [User ID [Signature ...] ...]
              [[Subkey [Binding-Signature-Revocation]
                      Primary-Key-Binding-Signature] ...]

---------

A keyring file is just a bunch of these concatenated together, i.e.
primary keys followed by the other subpackets.

Also see:

http://www.chem.swin.edu.au/~graeme/pgformat/

particularly public key ring overall structure.  There are postscript
versions of this on the net elsewhere, but I don't have a URL handy.

From: Thorsten Maly <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Documentation of PGP 2.6.x and PGP 5.x Keyring File Format
Date: Fri, 11 Sep 1998 12:18:50 +0200
Sender: [email-masked]

Does anybody know where I can find documentation/developer notes on the 
Keyring File Format for PGP 2.6.x or PGP 5.x. This aspect does not seem
to 
be covered in the draft, nor could I find any information on the web. 

Thanks in advance for any help.

Thorsten Maly
[email-masked]

Date: Fri, 11 Sep 98 02:17 +0200
From: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
To: [email-masked]
Subject: Re: Bug: Public-Key Encrypted Session Key Packets?
Organization: HR13
Sender: [email-masked]

The description of Public-Key Encrypted Session Key Packets is still
flawed in the 07 draft, as Ian Brown noted in a comment to the
previous draft.

>>5.1. Public-Key Encrypted Session Key Packets (Tag 1)
>>...
>>a two-octet checksum is appended which is equal to the
>>sum of the preceding octets, including the algorithm
>>identifier and session key, modulo 65536

The checksum is over the session key only, *not* including the
algorithm identifier.

From: Steve Hole <[email-masked]>
Date: Thu, 10 Sep 1998 08:55:35 -0600
To: Kazu Yamamoto <[email-masked]>
Subject: Re: Revising RFC 2015
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Message-ID: <[email-masked]>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version Mercury a9 Build (12)
MIME-Version: 1.0
Content-Type: Multipart/signed; BOUNDARY=Part9809100855.B; protocol="application/pgp-signature"; micalg=pgp-sha1

--Part9809100855.B
Content-Type: Text/PLAIN; CHARSET=US-ASCII

On Wed, 09 Sep 1998 20:28:22 +0900 Kazu Yamamoto <[email-masked]> wrote:

> Also, I proposed not to use multipart/encrypted since it's just
> lengthy(note: the first part is mostly empty). Ned suggested that it's
> nice to align PGP/MIME to the standard way(i.e. multipart security). I
> think this alignment is nice only if ALL encryption mail protocols
> align themselves since these protocol can share reporting mechanism to
> users(e.g. telling users that target objects were automatically
> decrypted). Then S/MIME comes and it doesn't use
> multipart/encrypted. Moreover, MOSS is going to historic. Currently, I
> don't see any reasons why PGP/MIME uses multipart encrypted. It's just
> lengthy.

Being one of the very few people that has implemented both PGP/MIME and S/MIME
into their mail products, I can tell you absolutely that the use of 
Multipart/Encrypted is a MUST.   Especially for IMAP4 mailers where access to
the MIME body structure allows a client to do intelligent things with an
encrypted body part.    You are simply wrong on this count.   I would fight
to the death any attempt to remove multipart/encrypted from the specification.

Cheers.
---  
Steve Hole                           
The Esys Corporation
Mailto:[email-masked]  
Phone:403-424-4922

--Part9809100855.B
Content-Type: Application/pgp-signature

--Part9809100855.B--

Date: Thu, 10 Sep 1998 11:29:56 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: the micalg parameter
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, Sep 10, 1998 at 07:10:22AM +0900, Kazu Yamamoto
wrote:

> > There is nothing in the RFC which says an implementation

> Which does this "the RFC" refer to, RFC 1847 or RFC 2015?

2015.  1847 says that certain conditions must be treated
as an error, but this doesn't mean that it has to be
evaluated at all.

> This interpretation is just yours. Since RFC2015 doesn't say accepting
> manner explicitly, there are two possibilities.

> 	(1) mis-match is legal
> 		-> MAY ignore the micalg parameter
> 	(2) mis-match is illegal
> 		-> treat it as garbage? (in your terminology)

Now, why do you think that a mis-match being illegal means
that an implementation can't be robust and ignore the
parameter in this case?  The behaviour is simply undefined, so 
the choice is yours - conform to the GIGO principle or try  
to handle things smoothly.

Actually, I find this situation just fine, so why should
anyone want to change it?

tlr

To: [email-masked]
Subject: the micalg parameter
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Thu, 10 Sep 1998 07:10:22 +0900
Lines: 44
Sender: [email-masked]

From: Thomas Roessler <[email-masked]>
Subject: Re: Revising RFC 2015
Date: Wed, 9 Sep 1998 14:34:02 +0200

> > I'd suggest that PGP/MIME implementations MUST enumerate
> > correct hash algorithms onto the micalg parameter when
> > generating and PGP/MIME implementations MAY ignore the
> > micalg parameters when accepting.
> 
> There is nothing in the RFC which says an implementation

Which does this "the RFC" refer to, RFC 1847 or RFC 2015?

> MUST evaluate the micalg parameter when accepting, so your
> letter point is precisely what's in the RFC right now.

OK, fine. I wrote my farmer sentence to make my explanation symmetric.
(I didn't claim any RFCs on this topic.)

> That hash algorithms MUST be listed correctly is evident
> from the text and doesn't need to be mentioned separately.

What do you mean "separately"? I didn't say anything about editorical
issues on this topic.

> If a user agent creates a message which doesn't conform to
> the spec, the receiver will conform to the GIGO principle:
> Garbage in, garbage out.  All this is not so new...

OK, this is the point of our debate.

This interpretation is just yours. Since RFC2015 doesn't say accepting
manner explicitly, there are two possibilities.

	(1) mis-match is legal
		-> MAY ignore the micalg parameter
	(2) mis-match is illegal
		-> treat it as garbage? (in your terminology)

Again, PGP/MIME RFC should define both syntax and its semantics. RFC
2015 defines syntax but some semantics are missing.

--Kazu

To: [email-masked]
Subject: the protocol parameter
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Thu, 10 Sep 1998 06:52:53 +0900
Lines: 36
Sender: [email-masked]

From: Thomas Roessler <[email-masked]>
Subject: Re: Revising RFC 2015
Date: Wed, 9 Sep 1998 14:34:02 +0200

> > I believe that the protocol parameter is case-insensitive
> > since it refers to content-type which is certainly
> > case-insensitive.
> 
> May I quote from RFC 2045?
> 
>    The type, subtype, and parameter names are not case
>    sensitive.  For example, TEXT, Text, and TeXt are all
>    equivalent top-level media types.  Parameter values are
>    normally case sensitive, but sometimes are interpreted
>    in a case-insensitive fashion, depending on the
>    intended use.  (For example, multipart boundaries are
>    case-sensitive, but the "access-type" parameter for
>    message/External-body is not case-sensitive.)
> 
> So, where precisely is your problem?

I said that RFC 1847 doesn't say the protocol parameter is
case-*in*sensitive.

RFC 2045 says that MIME parameter is case-sensitive unless explicitly
defined so.

According to these two things, readers think that the protocol
parameter is case-sensitive.

However, I think that the protocol parameter is case-*in*sensitive
since content-type is case-*in*sensitive as you quoted.

I'm talking about values of MIME parameter, not parameter name.

--Kazu

Date: Wed, 9 Sep 1998 15:21:50 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: New packets in PGP 6.0
Sender: [email-masked]

>>>>> "Jack" == Jack Repenning <[email-masked]> writes:

 Jack> At 10:02 AM 9/9/98 , Paul Koning wrote:
 >> No, but strings don't eliminate the registration problem, because
 >> you still need a way to ensure they are unique.  It's just that
 >> the code space is larger which simplifies that task.

 Jack> Strings don't eliminate the _need_ for registration, but they
 Jack> can piggy-back off existing registration systems (such as the
 Jack> DNS system for hostname registration) - which means the
 Jack> availability of strings, plus a convention such as the
 Jack> suggested one for using them, *does* eliminate the registration
 Jack> _problem_.

Yes, any identifying mechanism with hierarchy lets you piggyback off
an existing setup.  This is why a lot of identifiers are built using
the IEEE OUI as a component, and another bunch use OIDs for the same
reason.

DNS hostnames are actually not a good choice.  Unlike OUIs or OIDs,
DNS names are subject to cancellation or revocation if you don't pay
the yearly fee and/or have your chosen name challenged.

	paul

Date: Wed, 09 Sep 1998 12:20:00 -0700
To: [email-masked]
From: Jack Repenning <[email-masked]>
Subject: Re: New packets in PGP 6.0
Cc: Hal Finney <[email-masked]>, [email-masked]
Sender: [email-masked]

At 11:16 AM 9/9/98 , [email-masked] wrote:

>But is this on by default, or can I expect 99.5% of the PGP key packets I
>get from users and keyservers to have the new packets?

Compatibilty mode for key export is on by default (in the betas I saw, at
any rate).  But it's a persistent check box: the first time a 6.0 user
sends a key to another 6.0 user saying "look at my pretty face," and
eventually figures out why the face wasn't sent, that box will get
unchecked, and that user will start sending troublesome sig-blocks to pre-6
users.  The server-mediated exchange looks rugged to me, but the
user-mediated exchange is going to create confusion.  I dunno about 99.5%;
probably some more-disruptive figure, like 50%....

Date: Wed, 09 Sep 1998 12:14:03 -0700
To: Paul Koning <[email-masked]>
From: Jack Repenning <[email-masked]>
Subject: Re: New packets in PGP 6.0
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 10:02 AM 9/9/98 , Paul Koning wrote:

>No, but strings don't eliminate the registration problem, because you
>still need a way to ensure they are unique.  It's just that the code
>space is larger which simplifies that task.

Strings don't eliminate the _need_ for registration, but they can
piggy-back off existing registration systems (such as the DNS system for
hostname registration) - which means the availability of strings, plus a
convention such as the suggested one for using them, *does* eliminate the
registration _problem_.

Date: Wed, 9 Sep 1998 14:16:50 -0400
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: New packets in PGP 6.0
Sender: [email-masked]

On Wed, 9 Sep 1998, Hal Finney wrote:

> One thing more: PGP 6.0 has an option to export key packets in backwards
> compatible format, which will produce OpenPGP compliant messages.  This
> will strip off the Attribute ID packets.  So there is still an OpenPGP
> compliant mode.

But is this on by default, or can I expect 99.5% of the PGP key packets I
get from users and keyservers to have the new packets?

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 09 Sep 1998 13:15:43 -0500
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: New packets in PGP 6.0
Sender: [email-masked]

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

In <[email-masked]>, on 09/09/98 
   at 09:58 AM, Hal Finney <[email-masked]> said:

>The new photo id packets are not uploaded to older keyservers by the 6.0
>client.  They are only uploaded to NAI's version 2 LDAP keyservers (which
>is the version which ships with 6.0).  This version of the keyserver
>stores the photoid in a special data structure which will not be
>downloaded pre 6.0 clients.  Only PGP 6.0 knows to ask for data from this
>special data structure where photo ids are kept.

This brings me back to my second question:

Are there any plans for NAI to document the LDAP interface to their
certserver? It would come in handy for those of us developing OpenPGP
applications.

Now I can sift through the 5.5 source code that I have and examine the
packets 6.0 generates while communicating with the certserver but this is
a bit of a PITA.

It would be nice if someone at NAI would write up an informal paper
outlining the communication between the certserver and the client.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: I love running Windows! NOT!

Date: Wed, 9 Sep 1998 13:02:54 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: New packets in PGP 6.0
Sender: [email-masked]

>>>>> "Werner" == Werner Koch <[email-masked]> writes:

 Werner> "William H. Geiger III" <[email-masked]> writes:
 >> So lets say we have packet type 20 -- Generic ID. Then in the type
 >> field:
 >> 
 >> 10 -- PhotoID 15 -- Fingerprint 30 -- Retinal Scan

 Werner> Please do not continue with numeric ids; use strings (like
 Werner> ssh v2) to avoid all these number assignment problems.
 Werner> Numbers can still be assigned but a registration should not
 Werner> be required.  Compared to a size of Photo, the additionl
 Werner> bytes of a string don't count.

No, but strings don't eliminate the registration problem, because you
still need a way to ensure they are unique.  It's just that the code
space is larger which simplifies that task.

	paul

Date: Wed, 9 Sep 1998 09:58:30 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: New packets in PGP 6.0
Cc: [email-masked]
Sender: [email-masked]

William H. Geiger III, <[email-masked]>, writes:
> Well, part of the problem we are going to have here is once these new keys
> get uploaded to to the keyservers. It is my understanding that these new
> packets will break 5.x version of PGP.

Actually PGP 6.0 tries to take some care to avoid breaking existing
software.

The new photo id packets are not uploaded to older keyservers by the
6.0 client.  They are only uploaded to NAI's version 2 LDAP keyservers
(which is the version which ships with 6.0).  This version of the
keyserver stores the photoid in a special data structure which will not
be downloaded pre 6.0 clients.  Only PGP 6.0 knows to ask for data from
this special data structure where photo ids are kept.

When keys are exported explicitly, there is an option in the export
dialog box to cause the photo ids to be stripped, which defaults to the
backwards compatible mode.  The user must go to the advanced preferences
to change this default.

Therefore most users will only be sending their photo ids to the LDAP
keyserver, which will only provide them to 6.0 clients.  It is our
intention that photo ids will remain within the 6.0 "world" as much as
possible.

Hal Finney
Network Associates

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 09 Sep 1998 11:09:49 -0500
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: New packets in PGP 6.0
Sender: [email-masked]

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

In <[email-masked]>, on 09/09/98 
   at 08:00 AM, Hal Finney <[email-masked]> said:

>One thing more: PGP 6.0 has an option to export key packets in backwards
>compatible format, which will produce OpenPGP compliant messages.  This
>will strip off the Attribute ID packets.  So there is still an OpenPGP
>compliant mode.

Well, part of the problem we are going to have here is once these new keys
get uploaded to to the keyservers. It is my understanding that these new
packets will break 5.x version of PGP.

One approach would be to strip off these packets before they are accepted
to the keyservers. The other would be to add a PGP Version option to the
keyserver interface and have the server strip any non-compatiable packets
from the keys.

I have already written a utility that will strip the 5.x packets from
2.6.x keys. It would be simple enough to add code to strip the PhotoID
packets.

Are there any plans for NAI to documnet the LDAP interface to their
certserver? It would come in handy for those of us developing OpenPGP
aplications.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Win3.1? For fast relief call 800-3-IBM-OS2.

Date: Wed, 9 Sep 1998 17:37:51 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: New packets in PGP 6.0
Mail-Followup-To: [email-masked]
Sender: [email-masked]

"William H. Geiger III" <[email-masked]> writes:

> So lets say we have packet type 20 -- Generic ID. Then in the type field:
> 
> 10 -- PhotoID
> 15 -- Fingerprint
> 30 -- Retinal Scan

Please do not continue with numeric ids; use strings (like ssh v2) to
avoid all these number assignment problems.  Numbers can still be
assigned but a registration should not be required.  Compared to a
size of Photo, the additionl bytes of a string don't count.

And this does _not_ make the processing more complicated.

Werner

Date: Wed, 9 Sep 1998 08:00:32 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: New packets in PGP 6.0
Sender: [email-masked]

One thing more: PGP 6.0 has an option to export key packets in backwards
compatible format, which will produce OpenPGP compliant messages.  This
will strip off the Attribute ID packets.  So there is still an OpenPGP
compliant mode.

Hal

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 09 Sep 1998 08:42:17 -0500
To: [email-masked]
Subject: Re: New packets in PGP 6.0
Sender: [email-masked]

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

In <[email-masked]>, on 09/08/98 
   at 11:35 AM, Jon Callas <[email-masked]> said:

>You are indeed correct that it's a faux pas that it uses 17 for the
>packet id and not something in the 60-63 range. I argued the same thing
>here at NAI, but I lost that debate. I discussed it with John Noerenberg,
>who agreed that it was a faux pas, but not a big one -- especially given
>that the WG consensus was that there should be an implementation first.
>Nonetheless, I agree with you on *that* part of it wholeheartedly. The
>NAI developers are running the risk that OpenPGP 1.1 will define non-text
>user ids to be something incompatible with what they did for PGP 6, and
>they'll have to adapt.

>The PGP developers argued that they should not use the experimental range
>because doing so would de-facto use up that opcode because of all the
>copies of PGP 6 that would use it. I see their point, but I diagree.

Just to make things clear, I do not have a problem with NAI comming up
with something new for PGP, nor do I expect them to come to the WG for
permission to do so. My biggest objection was the grabbing of an
unassigned packet id without telling anyone about it. Now myself and
everyone else have to re-write their code to take these new packets into
account (any keys that I encounter with an unassigned packet id are
assumed to be in error and are rejected). Not major, but a PITA non the
less (FWIW I will be writting a patch for 5.0i when I have some free time
unless someone else feels up to it).

I really think that we need to establish some type of informal mechanism
for assigning numbers (packet, hash, algorithm, ect...) to prevent
problems in the future. I fear that things can get very ugly if we have 4
or 5 different vendors start using unassigned numbers whenever they have
something new to add.

Now as far as PhotoID's and ID's in general. I have mentioned in the past
for having some type of generic ID format that contained a type flag so
applications could invoke some type of sanity checking.

So lets say we have packet type 20 -- Generic ID. Then in the type field:

01 -- RFC822 E-Mail address
02 -- Real Name
03 -- Address
04 -- URL
05 -- X.500
10 -- PhotoID
15 -- Fingerprint
30 -- Retinal Scan

... ect

This seems to be a more sane approach than having a seperate packet type
for each ID format.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Air conditioned environment - Do not open Windows.

Tag-O-Matic: To whom the gods destroy, they first teach Windows...

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 09 Sep 1998 08:36:18 -0500
To: Thomas Roessler <[email-masked]>
Cc: [email-masked]
Subject: Re: New packets in PGP 6.0
Sender: [email-masked]

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

In <[email-masked]>, on 09/09/98 
   at 02:38 PM, Thomas Roessler <[email-masked]> said:

>On Wed, Sep 09, 1998 at 09:11:44AM +0200, Werner Koch wrote:

>> Suggestion for the future: Include some magic bytes to
>> packets in the experimental range, so you can decide
>> whether it is your experiment or not; same goes for the
>> experimental subkey types.

>Actually, one may wish to formalize a procedure for such
>private extensions.  The secsh (ssh) internet-drafts have
>a nice mechanism for this: They are using textual values
>for about all algorithm IDs, etc.  Experimental or local
>IDs always have the form <local id>@domain, where domain
>is a DNS domain under the control of the entity which
>creates the experimental ID.  For OpenPGP, one could think
>of an "experimental" packet ID which _must_ be followed by
>a string constant containing a local packet ID like the
>one I just described.  The rest of the packet will then
>conform to whatever the extension wants.

I don't know if I really like this as it complicates the packet processing
and is also not compatable with previous versions.

What we could do is make use of the marker packet to id experimental
packets.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: MASOCHIST: Windows SDK programmer with a smile!

Date: Wed, 9 Sep 1998 14:38:35 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: New packets in PGP 6.0
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Sep 09, 1998 at 09:11:44AM +0200, Werner Koch wrote:

> Suggestion for the future: Include some magic bytes to
> packets in the experimental range, so you can decide
> whether it is your experiment or not; same goes for the
> experimental subkey types.

Actually, one may wish to formalize a procedure for such
private extensions.  The secsh (ssh) internet-drafts have
a nice mechanism for this: They are using textual values
for about all algorithm IDs, etc.  Experimental or local
IDs always have the form <local id>@domain, where domain
is a DNS domain under the control of the entity which
creates the experimental ID.  For OpenPGP, one could think
of an "experimental" packet ID which _must_ be followed by
a string constant containing a local packet ID like the
one I just described.  The rest of the packet will then
conform to whatever the extension wants.

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

Date: Wed, 9 Sep 1998 14:34:02 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: Revising RFC 2015
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Sep 09, 1998 at 08:28:22PM +0900, Kazu Yamamoto
wrote:

> >   Clearly, this is a layer 1 incompatibility.

> Uhhhm. From the PGP/MIME implementors of view, I like to
> have semantics of this case. What kinds of action does
> PGP/MIME take?

As we are talking about layer 1 incompatiblities, OpenPGP
defines some behaviour for the PGP engine.  This behaviour
is passed to the PGP/MIME MUA.  So there is absolutely no
need to specify anything about such incompatibilities in a
PGP/MIME text.

>> - Alice encrypts a message with Bob's public key and
>>   sends it to Bob.  Now, this is an issue already dealt
>>   with in the OpenPGP draft, so it's out of the scope of
>>   PGP/MIME.

>> - Alice sends a public key to Bob, but Bob's PGP version
>>   is not able to handle this kind of public key.  Well,
>>   that's tough luck, so they won't be able to communicate
>>   securely.

> Ah-ha! Your point is that a sender can guess receiver's
> PGP version thanks to his public key.

> But with PGP 5.x spec, it is possible to encrypt a
> message with Triple DES, which can be not handled by PGP
> 2.x, whose session key is encrypted by RSA. I think that
> the story is not so simple.

I have to repeat myself: This is an issue which is dealt
with in the OpenPGP draft, so it's out of the scope of
PGP/MIME.

> I'd suggest that PGP/MIME implementations MUST enumerate
> correct hash algorithms onto the micalg parameter when
> generating and PGP/MIME implementations MAY ignore the
> micalg parameters when accepting.

There is nothing in the RFC which says an implementation
MUST evaluate the micalg parameter when accepting, so your
letter point is precisely what's in the RFC right now.

That hash algorithms MUST be listed correctly is evident
from the text and doesn't need to be mentioned separately.

If a user agent creates a message which doesn't conform to
the spec, the receiver will conform to the GIGO principle:
Garbage in, garbage out.  All this is not so new...

> Please remember my conceptual model. PGP/MIME UA must
> tell what kind of symmetric crypto (and more) to PGP
> engine. (2.1)

That's an issue _every_ PGP front-end has to deal with. It
isn't MIME-specific at all.  Additionally, the OpenPGP
spec does already deal with this issue.  May I point you
to section 5.2.3.6 of the draft?

> (2.3) is semantic issue of PGP/MIME.

Sorry, no.  This is a semantic issue of _any_ OpenPGP
implementation, at any layer, and it's not at all specific
to PGP/MIME.  (2.3 was the question what kind of action a
MUA should take if it receives unrecognized PGP packets.)

>> 2.4 and 2.5 are yet another category: Here, you are
>> dealing with general MIME handling.  Now, this is an
>> issue to be handled in the "generic" MIME documents, but
>> once again not in a PGP/MIME text.  For the purpose of
>> PGP/MIME, we can simply assume that a MUA should behave
>> according to the generic texts.

(2.4 and 2.5 were the question what kinds of MIME
content-types am MUA must be able to handle and generate
in order to conform to the spec.)

> Maybe. Nonetheless, implementation note of this kind is
> useful to let implementators program correctly.

Pardon me?  The content-types supported by a MUA have
absolutely nothing to do with PGP/MIME; they have
everything to do with MIME.  Essentially, this is a
decision you have to make as a MUA author.  Your
"customers" will tell you if your program is usable or
not.

>>> MIME clearly defines any MIME parameters are
>>> case-*sensitive* if it is not defined so. And RFC 1847
>>> doesn't say the protocol parameter is case-insensitive.

>> So it's case-sensitive in PGP/MIME as well, that's what
>> I've said.  Where's the problem with that?

> I believe that the protocol parameter is case-insensitive
> since it refers to content-type which is certainly
> case-insensitive.

May I quote from RFC 2045?

   The type, subtype, and parameter names are not case
   sensitive.  For example, TEXT, Text, and TeXt are all
   equivalent top-level media types.  Parameter values are
   normally case sensitive, but sometimes are interpreted
   in a case-insensitive fashion, depending on the
   intended use.  (For example, multipart boundaries are
   case-sensitive, but the "access-type" parameter for
   message/External-body is not case-sensitive.)

So, where precisely is your problem?

tlr   
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

To: [email-masked]
Cc: [email-masked]
Subject: Re: Revising RFC 2015
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Wed, 09 Sep 1998 20:28:22 +0900
Lines: 202
Sender: [email-masked]

Thomas, 

Sorry for my late response. I was busy for the last few day.

From: Thomas Roessler <[email-masked]>
Subject: Re: Revising RFC 2015
Date: Fri, 4 Sep 1998 14:38:25 +0200

> Let me elaborate my point in a different manner.  We have
> several layers between which we should distinguish:

[deleted]

> Layers 1-3 (including ascii armor for signatures) are
> specified in the OpenPGP draft and should be handled as
> mostly opaque by a PGP/MIME text (they are by RFC 2015).
> If there are problems on these layers, they should be
> dealt with in the next generation OpenPGP RFC.

This layer model seems good.

But I have another *conceptual* model. (Probably we are explaining the
same thing with different terminology.) In my model, there are two
entities: PGP/MIME MUA and PGP engine. The PGP/MIME MUA drives the PGP
engine.

So, PGP/MIME should
	(1) define PGP/MIME formant
and
	(2) provide necessary information for MUAs to drive PGP engines.

> Layers three and four are pretty much the interface
> between MUA and PGP application.  Essentially, one of the
> two mappings applied is usually the identity, while the
> other one is more or less base64.

This is perhaps the same of my conceptual model.

> - Alice signs a message with a key and/or signature format
>   which is not understood by Bob's software.  In this
>   case, Bob's software will kindly bail out and tell him
>   that the signature can't be verifyed for this and that
>   reason.  Nevertheless, Bob's MUA will be able to display
>   the text of the message since the message is present in
>   MIME clear-text.

Right.

>   Clearly, this is a layer 1 incompatibility.

Uhhhm. From the PGP/MIME implementors of view, I like to have
semantics of this case. What kinds of action does PGP/MIME take?

> - Alice encrypts a message with Bob's public key and sends
>   it to Bob.  Now, this is an issue already dealt with in
>   the OpenPGP draft, so it's out of the scope of PGP/MIME.
> - Alice sends a public key to Bob, but Bob's PGP version
>   is not able to handle this kind of public key.  Well,
>   that's tough luck, so they won't be able to communicate
>   securely.

Ah-ha! Your point is that a sender can guess receiver's PGP version
thanks to his public key.

But with PGP 5.x spec, it is possible to encrypt a message with Triple
DES, which can be not handled by PGP 2.x, whose session key is
encrypted by RSA. I think that the story is not so simple.

> All this means that there are no version control issues to
> be dealt with on the MIME layer, so I think we should
> leave them out.

Sorry, I disagree. Please see below.

> OK, fine with me.  Can I state the consensus that we leave
> everything as it is now and simply add the new hash
> algorithms?

I agree. But please define semantics for mismatch between 
the micalg parameter and parameters inside PGP packets. 

I'd suggest that PGP/MIME implementations MUST enumerate correct hash
algorithms onto the micalg parameter when generating and PGP/MIME
implementations MAY ignore the micalg parameters when accepting.

> >>> (2.1) What kinds of algorithm (for symmetric crypt,
> >>> asymmetric crypt, hash) is preferred when generated?
> >>> (2.3) What kind of actions should be taken if MUA
> >>> receives unrecognized PGP packets?
> >>> (2.4) Generating: what kind of content-type must MUA be
> >>> able to generate? If MUA can sign only text/plain, is it
> >>> conformable?
> >>> (2.5) Accepting: what kind of content-type must MUA be
> >>> able to handle? If MUA can't verify signed text/plain
> >>> under multipart/mixed, is it conformable?
> > This is not a format issue but a standardization issue.
> > Thus certainly protocol issue. Recently, many other
> > protocols define minimum conformant set for generating
> > and accepting.
> Let's revisit these points, and let's think layers while
> doing so.
> 
> 2.1, 2.2 and 2.3 are clearly issues on layers one and two,
> so I'd consider them to be outside the scope of the
> PGP/MIME spec.

No. Please remember my conceptual model. PGP/MIME UA must tell what
kind of symmetric crypto (and more) to PGP engine. (2.1)

(2.3) is semantic issue of PGP/MIME.

> 2.4 and 2.5 are yet another category: Here, you are
> dealing with general MIME handling.  Now, this is an issue
> to be handled in the "generic" MIME documents, but once
> again not in a PGP/MIME text.  For the purpose of
> PGP/MIME, we can simply assume that a MUA should behave
> according to the generic texts.

Maybe. Nonetheless, implementation note of this kind is useful to let
implementators program correctly.

> So if we want to drop ASCII armor on the long run, we
> should do so _everywhere_.

I agree. 

I don't know you know the old discussions on PGP/MIME when RFC2015 was
IDs. Actually, I proposed to use MIME encoding instead of ASCII armor
at that time. This proposal was rejected but I couldn't see any
technical reasons why rejected.

To my experiences, ASCII armor is less friendly to non-PGP/MIME UAs
than it seems to be. PGP/MIME signed objects can't be verify by the
PGP program(note: PGP 5.0 can do this if compiled with the MIMEPARSE
macro). So, the second part, detached signature, is not necessary to
be encoded with ASCII armor.

For PGP/MIME encrypted object, RFC2015 is not friendly to the PGP
program, neither. Yes, the object can be decrypted by PGP but it is
not so easy to remove MIME header preceding the target object. Please
imagine that you remove CT: preceding a GIF image file by your editor.
All in all, manual processing is necessary and MIME encoding programs
are out there. So, I don't see any technical reasons for ASCII armor.

Also, I proposed not to use multipart/encrypted since it's just
lengthy(note: the first part is mostly empty). Ned suggested that it's
nice to align PGP/MIME to the standard way(i.e. multipart security). I
think this alignment is nice only if ALL encryption mail protocols
align themselves since these protocol can share reporting mechanism to
users(e.g. telling users that target objects were automatically
decrypted). Then S/MIME comes and it doesn't use
multipart/encrypted. Moreover, MOSS is going to historic. Currently, I
don't see any reasons why PGP/MIME uses multipart encrypted. It's just
lengthy.

Anyway, past is past. This is just for your information.

> A suggestion on this topic:
> 
> - Implementations MUST be able to accept ASCII armor
>   representations of PGP objects.  They SHOULD be able to
>   accept the binary representation.

I like to change the last SHOULD to MUST because accepting syntax is
like that.

> >>> (4.1) Why not text/pgp?
> 
> >>> (4.2) S/MIME doesn't use multipart/encrypted. Why does
> >>> PGP/MIME?

> > No. RFC is the best place to answer any technical
> > questions. 
> 
> Correct.  But RFCs are _not_ the best place to extensively
> discuss the rationale behind certain basic decisions.
> Specifically, an RFC which is merely a revised version of
> an existing one should not start to explain the design
> decisions behind that existing RFC.  (IMHO)

OK, let me enumerate an example with my IPsec hat.

The IPsec architecture draft explains why two protocols, namely AH and
ESP, are provided.

Also, RFC2015 starts with objections to the application/pgp approach.

# I don't like this relative prologue. I think that PGP/MIME RFC
# should start with "why PGP/MIME". Comparison with other approaches
# should go to a later session.

> > MIME clearly defines any MIME parameters are
> > case-*sensitive* if it is not defined so. And RFC 1847
> > doesn't say the protocol parameter is case-insensitive.
> 
> So it's case-sensitive in PGP/MIME as well, that's what
> I've said.  Where's the problem with that?

I believe that the protocol parameter is case-insensitive since it
refers to content-type which is certainly case-insensitive. 

--Kazu

Date: Wed, 9 Sep 1998 09:11:44 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: New packets in PGP 6.0
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> The PGP developers argued that they should not use the experimental range
> because doing so would de-facto use up that opcode because of all the
> copies of PGP 6 that would use it. I see their point, but I diagree.

Suggestion for the future:  Include some magic bytes to packets in the
experimental range, so you can decide whether it is your experiment or
not; same goes for the experimental subkey types.

Werner 

Date: Tue, 08 Sep 1998 11:35:11 -0700
To: "William H. Geiger III" <[email-masked]>, "William Allen Simpson" <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: New packets in PGP 6.0
Cc: [email-masked]
Sender: [email-masked]

A number of things:

To Bill Geiger:

Bill, this isn't the first anyone's heard of the picture ID packets. I made
a proposal that we discuss them in draft -00. I distinctly remember
discussing the issue with you in Washington, and told you that they were on
our schedule for 6.0. Phil made a couple of pleas for them, and Hal
submitted a definition suggestion to the list. It was met with a resounding
thud. William Simpson argued forcefully against them for 1.0, and since the
only people who really seemed to be *for* them were NAI people, I let the
issue drop. Ironically, the reason for *not* putting them in V1.0 was that
no one has implemented them, so they should get field experience before
going in the standard.

I admit that I did not raise a huge stink over the issue, but if you
weren't aware of it, then you weren't reading your mail. I've worked hard
to balance being the spec editor along with working on PGP. I let that
issue drop because I felt that pursuing it any further would be ramrodding
a feature into the spec just because we implemented it, especially with the
WG saying there should be implementation experience *before* the feature
went in the spec. I did keep the WG chair informed of the entire situation,
though. 

You are indeed correct that it's a faux pas that it uses 17 for the packet
id and not something in the 60-63 range. I argued the same thing here at
NAI, but I lost that debate. I discussed it with John Noerenberg, who
agreed that it was a faux pas, but not a big one -- especially given that
the WG consensus was that there should be an implementation first.
Nonetheless, I agree with you on *that* part of it wholeheartedly. The NAI
developers are running the risk that OpenPGP 1.1 will define non-text user
ids to be something incompatible with what they did for PGP 6, and they'll
have to adapt.

The PGP developers argued that they should not use the experimental range
because doing so would de-facto use up that opcode because of all the
copies of PGP 6 that would use it. I see their point, but I diagree.

To William Simpson:

It has *not* been over a year for the spec. The OpenPGP BOF was in Munich,
Aug '97. The approval from the IESG came on Sept 18. Yes, it took me nearly
two months to get the -00 draft out, but I disagree completely that the
whole process could have been done in substantially shorter time. The two
major complaints I've gotten about the pace have been that we're taking too
long and that we're moving too fast. Even at the langorous pace we've
taken, we've only gotten where we are by aggressively deferring issues.
Getting complaints about pace from both directions is to me a pretty good
indicator that we're somewhere in the "fast enough" range even if it's at
the slow end of that range.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: OpenPGP Message Format to Proposed Standard
Reply-to: [email-masked]
Date: Tue, 08 Sep 1998 14:16:39 -0400
Sender: [email-masked]

The IESG has received a request from the Open Specification for Pretty
Good Privacy Working Group to consider OpenPGP Message Format
<draft-ietf-openpgp-formats-07.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by September 22, 1998.

Files can be obtained via
ftp://ftp.ietf.org/internet-drafts/draft-ietf-openpgp-formats-07.txt

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 07 Sep 1998 11:22:30 -0500
To: "William Allen Simpson" <[email-masked]>
Cc: [email-masked]
Subject: Re: New packets in PGP 6.0
Sender: [email-masked]

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

In <[email-masked]>, on 09/07/98 
   at 12:56 PM, "William Allen Simpson" <[email-masked]> said:

>As I have to keep reminding folks every few months, the charter of this
>WG was to update the old RFC-1991, document the actual design of PGP 5.0,
>make some choices about what we were going to keep (IETF assumes change
>control), and specifically was supposed to avoid disenfranchising earlier
>PGP users.

>The second deliverable, which as I remember was a PKI, we dropped from
>the Charter.

>This was not supposed to include 5.5, and certainly not 6.0.

>Unfortunately, Callas turned out to be incredibly slow at writing
>documentation.  A typical programmer problem.  So, what should have taken
>at most 3-4 months, took over a year.

>Meanwhile, they've come out with new versions.  Can you blame them? Silly
>folks are trying to make enough to keep eating....

William,

I would have taken someone at NAI a whole 5 mins to drop a note to the
list saying "by the way we would like to reserver packet types 16-20 for
some stuff we are playing with". Or even better they could have used the
private/experimental range of packet numbers 60-63.

I don't know about you, but I do not like the idea off all unassigned
numbers in the RFC being reserved for NAI use.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: OS/2: Taking the wind out of Windows.

Date: Mon, 7 Sep 98 12:56:00 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: Re: New packets in PGP 6.0
Sender: [email-masked]

As I have to keep reminding folks every few months, the charter of this
WG was to update the old RFC-1991, document the actual design of PGP
5.0, make some choices about what we were going to keep (IETF assumes
change control), and specifically was supposed to avoid disenfranchising
earlier PGP users.

The second deliverable, which as I remember was a PKI, we dropped from
the Charter.

This was not supposed to include 5.5, and certainly not 6.0.

Unfortunately, Callas turned out to be incredibly slow at writing
documentation.  A typical programmer problem.  So, what should have
taken at most 3-4 months, took over a year.

Meanwhile, they've come out with new versions.  Can you blame them?
Silly folks are trying to make enough to keep eating....

> From: "William H. Geiger III" <[email-masked]>
> What exactly is the point of having a RFC if the PGP guys at NAI are not
> going to follow it? I had made the assumption that the PhotoID was being
> added as a subpacket to the self-signature, as this would be supported by
> the I-D and seemed like a logical place to put it.
>
But we don't have to follow them.  Let's put the packet in the right
place in a "modifications" RFC.  I'm sure they will come out with a 6.1
to follow the IETF. :-)

> Note to the NAI people on the list:
>
> You guys have know about this PhotoID for some time now. Why is it that we
> are only hearing about this now? And even more germane, why are we hearing
> about it from someone other than one of you?
>
> If every time NAI makes a new release we have to hack through the code and
> the output, what is the point of having an RFC at all?? It does not bode
> well for a standard when the principle vendor breaks it with their 1st
> release.
>

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 07 Sep 1998 03:14:33 -0500
To: [email-masked], [email-masked]
Subject: OT: KRAP is at it in the IETF
Sender: [email-masked]

Sorry for the off-topic post but it seemd of interest to members of the
list. Please follow up off list.

Thanks,

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

Hello,

It has come to my attention that the KRAP (key recovery alliance program)
has submitted an I-D (internet draft) to the IETF for adding GAK
(government access to keys) to the IPSEC protocols:

ftp://ftp.ietf.org/internet-drafts/draft-rfced-exp-markham-00.txt

ISAKMP Key Recovery Extensions
<draft-rfced-exp-markham-00.txt>

7. AUTHOR INFORMATION

   Tom Markham
   Secure Computing Corp
   2675 Long Lake Road
   Roseville, MN 55113   USA

   Phone: 651.628.2754,    Fax:   651.628.2701
   EMail: [email-masked]

I consider this a perversion of the standards process of the IETF to
advance a political agenda which must be stopped at all cost.

Below are the e-mail addresses of some people that you should write
(politely) expressing your objections to any such additions to the
protocols:

IPSEC Chairs:

Theodore Ts'o <[email-masked]>
Robert Moskowitz <[email-masked]>

Security Area Directors:

Jeffrey Schiller <[email-masked]>
Marcus Leech <[email-masked]>

As I mentioned before, be polite. These people are not the ones proposing
GAK be added to the IPSEC protocols. They have put a lot of time and
effort in forwarding the cause for strong encryption. They should be made
aware of the communities objections to these attempts by KRAP.

Thanks,

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: It's OS/2, Jim, but not OS/2 as we know it.

Tag-O-Matic: Win3.1? For fast relief call 800-3-IBM-OS2.

Date: Sun, 6 Sep 1998 11:23:58 +0200
From: Thomas Roessler <[email-masked]>
To: IETF OpenPGP <[email-masked]>
Subject: Re: Revising RFC 2015
Mail-Followup-To: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

On Sat, Sep 05, 1998 at 11:25:13AM +0000, Lindsay
Mathieson wrote:

> 1.	Every existing MIME implementation has base64
> encoding code (which is exactly the same as ASCII armour,
> minus the CRC

correct.

> 2.	The MIME spec ban's nested encodings of MIME
> objects

Correct, but irrelevant.

When signing messages and sending keys according to the
PGP/MIME RFC, no nested encoding of MIME objects occurs.
And, additionally, the "no nested encodings" stuff simply
doesn't apply if we are talking about _encrypting_ MIME
objects.

> 3.	Every PGP implementation to date may have ASCII
> Armour, but they should also have a binary output option
> - certainly PGP itself does. This works well with RFC
> 1847 & 2015 as the PGP binary object can be attached and
> encoded with base64.

Pardon me?  RFC 2015 mandates ASCII armor, not MIME
encoding for PGP encrypted objects.

> 4.	Using ASCII Armour would break most MIME
> implementations and *really* annoy the MIME team.

Is it remotely possible that you don't really understand
what this discussion is about?  ASCII armor is _only_
relevant for PGP objects which are fed into some PGP
backend unchanged.  These objects are handled as opaque by
MUAs, so using ASCII armor here just means that MUAs don't
need to care about MIME decoding at this point.

Additionally, it means that these folks who use non-MIME
MUAs may be able to process the PGP objects "manually"
(editor + pgp).

To make a long story short: Try reading RFC 2015.  Try
reading some code which implements it.  Try processing
messages which conform to 2015 with non-PGP enabled MIME
MUAs.  Try processing them manually.

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

Date: 5 Sep 1998 11:25:13 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: Revising RFC 2015
To: "William H. Geiger III" <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>We are not bringing up this old ghost are we? Every PGP implementation
>to date uses ASCII-Armor, it is there and everyone has the code for it.
>Using anything other than Ascii-Armor for 8bit to 7bit conversion of
>PGP packets only complicates the issue.

This is no old ghost, and needs to be settled. I am absolutley opposed to
using ASCII armour with MIME.

1.	Every existing MIME implementation has base64 encoding code (which is
exactly the same as ASCII armour, minus the CRC

2.	The MIME spec ban's nested encodings of MIME objects

3.	Every PGP implementation to date may have ASCII Armour, but they should
also have a binary output option - certainly PGP itself does. This works
well with RFC 1847 & 2015 as the PGP binary object can be attached and
encoded with base64.

4.	Using ASCII Armour would break most MIME implementations and *really*
annoy the MIME team.
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Vs 2.8 Preview 2, on September 5, 1998, in
Win95 4.0
	http://www.blackpaw.com/

From: "William H. Geiger III" <[email-masked]>
Date: Sat, 05 Sep 1998 17:44:34 -0500
To: [email-masked]
Cc: [email-masked]
Subject: Re: New packets in PGP 6.0
Sender: [email-masked]

In <[email-masked]>, on 09/05/98 
   at 11:19 PM, Patrick Feisthammel <[email-masked]> said:

>Hi!

>The PGP 6.0 seems to introduce new packet types. 

>The photo pictures are in a package with the tag 17.
>The signature binding the photo to the key seems to be a normal sig of 
>type 0x10 (Generic certification of a UserID and Public Key Packet).

>Some questions arise:

>1. Is it save to ignore any unknown packet? 
>If yes, perhaps it shoul be added to the -08 spec after the list of
>packet tags in the chapter "Packet Tags".

>2. What format do the x.509 keys have in PGP 6.0 keyrings?
>(Does someone have a sample?) 

>3. Will Open PGP support x.509 keys? I found some discussing on the list
>but no final decision.

>4. For the keyserver folks: PGP 6.0 seams to strip the image packets, if
>the keyserver is not a Certificate Server 2.0...

I find this quite troubling.

What exactly is the point of having a RFC if the PGP guys at NAI are not
going to follow it? I had made the assumption that the PhotoID was being
added as a subpacket to the self-signature, as this would be supported by
the I-D and seemed like a logical place to put it.

Note to the NAI people on the list:

You guys have know about this PhotoID for some time now. Why is it that we
are only hearing about this now? And even more germane, why are we hearing
about it from someone other than one of you?

If every time NAI makes a new release we have to hack through the code and
the output, what is the point of having an RFC at all?? It does not bode
well for a standard when the principle vendor breaks it with their 1st
release.

I am not happy with this at all.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
---------------------------------------------------------------

Date: Sat, 5 Sep 1998 23:19:20 +0200 (CEST)
From: Patrick Feisthammel <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: New packets in PGP 6.0
Sender: [email-masked]

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

Hi!

The PGP 6.0 seems to introduce new packet types. 

The photo pictures are in a package with the tag 17.
The signature binding the photo to the key seems to be a normal sig of 
type 0x10 (Generic certification of a UserID and Public Key Packet).

Some questions arise:

1. Is it save to ignore any unknown packet? 
If yes, perhaps it shoul be added to the -08 spec after the list of packet
tags in the chapter "Packet Tags".

2. What format do the x.509 keys have in PGP 6.0 keyrings?
(Does someone have a sample?) 

3. Will Open PGP support x.509 keys? I found some discussing on the list
but no final decision.

4. For the keyserver folks: PGP 6.0 seams to strip the image packets, if
the keyserver is not a Certificate Server 2.0...

Cheers,
Patrick

- ---
PGP-KeyID: DD934139 ([email-masked])    encrypt mail with PGP if possible
more about PGP on http://www.rubin.ch/pgp/ (english and german)
what ist the web of trust? see http://www.rubin.ch/pgp/weboftrust.en.html
Das Vertrauensnetz von PGP:    http://www.rubin.ch/pgp/weboftrust.de.html

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 04 Sep 1998 08:53:07 -0500
To: [email-masked]
Subject: Re: Revising RFC 2015
Sender: [email-masked]

In <[email-masked]>, on 09/04/98 
   at 07:22 AM, Kazu Yamamoto ($B;3K\OBI'(B) <[email-masked]> said:

>> > (3) Others
>> 
>> > (3.1) Some people want to encode PGP signature and/or
>> > encrypted message with MIME encoding(e.g not PGP armor
>> > but base64). Should we allow this?
>> 
>> I don't see any benefits from this. 

>And I don't see any benefits of PGP armor when used to encode detached
>signatures. Note I can see benefits of PGP armor when used to encode
>encrypted message for backward compatibility.

We are not bringing up this old ghost are we? Every PGP implementation to
date uses ASCII-Armor, it is there and everyone has the code for it. Using
anything other than Ascii-Armor for 8bit to 7bit conversion of PGP packets
only complicates the issue.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
---------------------------------------------------------------

Date: Fri, 4 Sep 1998 14:38:25 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: Revising RFC 2015
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Executive summary:

- I'm dropping my pkalg suggestion.
- There seems to be consensus on micalg.
- A suggestion with respect to ASCII armor and and binary
  representation of PGP objects is made.

On Fri, Sep 04, 1998 at 07:22:49AM +0900, Kazu Yamamoto
wrote:

> If the purpose of the pkalg parameter is to distinguish
> PGP format version in MUA level, how about version
> control that I mentioned? 

You got me on this one.  Ok, just forget what I wrote
about different PGP versions.

> (e.g The pgpmime-version parameter for
> application/pgp-signature.) This approach is, I think,
> symmetric if we will decide Version: in
> application/pgp-encrypted.

Let me elaborate my point in a different manner.  We have
several layers between which we should distinguish:

1. Inner PGP packets.  These beasts consist of a packet
   type, version byte, and lots of information.  What
   packets are handled depends from implementation to
   implementation.  E.g., pgp 2 only handles v2 packets,
   OpenPGP compliant software handles v2 and v3 packets,
   etc.

   Most important, implementations should be able to
   graciously bail out upon unknown packets or packet
   versions.

2. Outer PGP packets.  By this, I denote the encapsulation
   of "inner packets", mostly consisting of the packet tag
   and length bytes.

   A new style outer packet can carry any inner packet; an
   old style outer packet an carry any inner packet with a
   3-bit packet tag.

   PGP 2 is about the only implementation which can't
   handle new-style outer packets.  It should be pretty
   simple to add this support (Lutz, have you done it in
   2.6.3in?), so we can IMTAO assume that pretty much
   every implementation in common use can handle these
   packets sooner or later.

(Both are called "packet" in the OpenPGP draft.  Maybe we
should change this in the next version?)
   
3. Packet representation.  PGP knows about two of them:
   ASCII armor and binary.

4. MIME encoding.  This is the encoding we apply at the
   MIME level.

5. MIME encapsulation.

Layers 1-3 (including ascii armor for signatures) are
specified in the OpenPGP draft and should be handled as
mostly opaque by a PGP/MIME text (they are by RFC 2015).
If there are problems on these layers, they should be
dealt with in the next generation OpenPGP RFC.

Layers three and four are pretty much the interface
between MUA and PGP application.  Essentially, one of the
two mappings applied is usually the identity, while the
other one is more or less base64.

Now, let's revisit the version control problem.

Three things can happen with the content types currently
supported by PGP/MIME:

- Alice signs a message with a key and/or signature format
  which is not understood by Bob's software.  In this
  case, Bob's software will kindly bail out and tell him
  that the signature can't be verifyed for this and that
  reason.  Nevertheless, Bob's MUA will be able to display
  the text of the message since the message is present in
  MIME clear-text.

  Clearly, this is a layer 1 incompatibility.

- Alice encrypts a message with Bob's public key and sends
  it to Bob.  Now, this is an issue already dealt with in
  the OpenPGP draft, so it's out of the scope of PGP/MIME.

- Alice sends a public key to Bob, but Bob's PGP version
  is not able to handle this kind of public key.  Well,
  that's tough luck, so they won't be able to communicate
  securely.

  Once again, this is a problem on layer 1.

All this means that there are no version control issues to
be dealt with on the MIME layer, so I think we should
leave them out.

Now, for the MIME parameters.  If we apply the model
above, the pkalg parameter I proposed for signature body
parts should be left out.

I'm completely clear about the fact that this leaves MUAs
who support several back-ends in parallel in the rain;
such software would have to try every back-end in turn, or
implement a back-end selection on the lower levels on the
protocol.

About micalg, you write:

> What I wanted to say is that the parameter itself seems
> less useful than we expected. The micalg parameter is
> defined with the hope that it is useful for one pass
> verification. But I don't know any implementations use
> it.

> Since future implementations may make use of this
> parameter, I'm not particular to this topic.

OK, fine with me.  Can I state the consensus that we leave
everything as it is now and simply add the new hash
algorithms?

>>> (2) Conformance

>>> (2.1) What kinds of algorithm (for symmetric crypt,
>>> asymmetric crypt, hash) is preferred when generated?

>>> (2.3) What kind of actions should be taken if MUA
>>> receives unrecognized PGP packets?

>>> (2.4) Generating: what kind of content-type must MUA be
>>> able to generate? If MUA can sign only text/plain, is it
>>> conformable?

>>> (2.5) Accepting: what kind of content-type must MUA be
>>> able to handle? If MUA can't verify signed text/plain
>>> under multipart/mixed, is it conformable?

> This is not a format issue but a standardization issue.
> Thus certainly protocol issue. Recently, many other
> protocols define minimum conformant set for generating
> and accepting.

Let's revisit these points, and let's think layers while
doing so.

2.1, 2.2 and 2.3 are clearly issues on layers one and two,
so I'd consider them to be outside the scope of the
PGP/MIME spec.

2.4 and 2.5 are yet another category: Here, you are
dealing with general MIME handling.  Now, this is an issue
to be handled in the "generic" MIME documents, but once
again not in a PGP/MIME text.  For the purpose of
PGP/MIME, we can simply assume that a MUA should behave
according to the generic texts.

>>> (3) Others

>>> (3.1) Some people want to encode PGP signature and/or
>>> encrypted message with MIME encoding(e.g not PGP armor
>>> but base64). Should we allow this?

>> I don't see any benefits from this. 

> And I don't see any benefits of PGP armor when used to
> encode detached signatures. Note I can see benefits of
> PGP armor when used to encode encrypted message for
> backward compatibility.

That's correct, but:

>> On the other hand, this would break existing software
>> which relies on the content-transfer-encoding
>> restrictions in RFC 2015. => Don't do this.

> But many implementation of PGP/MIME can handle it (e.g.
> encoded signature with base64), I guess. At least, my
> implementation can do it though it is not my intention.

It's nice that your implementation has this extension of
the required behaviour, making it more robust.  But other
implementations which comply to the current RFC may _not_
have this extension.  We should _not_ deliberately break
that software without good reasons.

Additionally, there is the consistency argument: I don't
think having different content transfer encoding
restrictions for every content type we define is a good
thing.

So if we want to drop ASCII armor on the long run, we
should do so _everywhere_.

A suggestion on this topic:

- Implementations MUST be able to accept ASCII armor
  representations of PGP objects.  They SHOULD be able to
  accept the binary representation.

- Implementations MUST be able to generate ASCII armor
  representations, and they SHOULD NOT generate the binary
  representation.

This should open a smooth upgrade path for the case that
ASCII armor is finally dropped from some future version of
the OpenPGP document.

>>> (4.1) Why not text/pgp?

>>> (4.2) S/MIME doesn't use multipart/encrypted. Why does
>>> PGP/MIME?

> No. RFC is the best place to answer any technical
> questions. 

Correct.  But RFCs are _not_ the best place to extensively
discuss the rationale behind certain basic decisions.
Specifically, an RFC which is merely a revised version of
an existing one should not start to explain the design
decisions behind that existing RFC.  (IMHO)

>>> (5.2) No RFC says that the protocol paramter is
>>> case-insensitive.

>> So it isn't.  Where's the problem here?

> MIME clearly defines any MIME parameters are
> case-*sensitive* if it is not defined so. And RFC 1847
> doesn't say the protocol parameter is case-insensitive.

So it's case-sensitive in PGP/MIME as well, that's what
I've said.  Where's the problem with that?

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

Date: Thu, 3 Sep 1998 16:32:11 -0700
To: Jon Callas <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: language tag
Cc: Paul Hoffman / IMC <[email-masked]>, Jon Callas <[email-masked]>, [email-masked]
Sender: [email-masked]

At 1:52 PM -0700 9/3/98, Jon Callas wrote:
>I've already started a -08 draft, on the off chance it's needed. The only
>things in it are Ulf Moeller's implementation note, and adding an L to all
>the constants in the CRC sample code. Does anyone else have an opinion
>anout the words "human-readable"?

Leave them in.  I took the interpretation on rendering UTF-8 that you did.

john noerenberg
[email-masked]
  ----------------------------------------------------------------------
  --if we are to be saved, it will not be by Romans but by saints.
  -- Thomas Cahill, "how the Irish Saved Civilization", 1995
  ----------------------------------------------------------------------

Date: Thu, 3 Sep 1998 16:41:26 -0700
To: [email-masked]
From: "John  W. Noerenberg" <[email-masked]>
Subject: Watch for IETF Last Call
Sender: [email-masked]

I expect to see an IETF Last Call announcement on IETF-Announce soon.  Jeff
Schiller plans to ask for one now that he has the -07 draft.

john noerenberg
[email-masked]
  ----------------------------------------------------------------------
  --if we are to be saved, it will not be by Romans but by saints.
  -- Thomas Cahill, "how the Irish Saved Civilization", 1995
  ----------------------------------------------------------------------

To: [email-masked]
Subject: Re: Revising RFC 2015
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Fri, 04 Sep 1998 07:22:49 +0900
Lines: 190
Sender: [email-masked]

From: Thomas Roessler <[email-masked]>
Subject: Revising RFC 2015
Date: Thu, 3 Sep 1998 20:37:20 +0200

> >- We may wish to require another parameter with the
> >  application/pgp-signature body parts, namely, "pkalg".
> >  This parameter would identify the public key algorithm
> >  used to generate the signature, e.g., rsa, elgamal, dsa,
> >  etc.
> 
> >  The rationale behind this is that mail user agents may
> >  wish to invoke different external OpenPGP
> >  implementations to verify different kinds of signatures
> >  - e.g., pgp 2 for RSA/MD5, pgp 5 for DSA/SHA1, and gpg
> >  for RSA/RMD160, RSA/SHA1, and so forth.

If the purpose of the pkalg parameter is to distinguish PGP format
version in MUA level, how about version control that I mentioned? (e.g
The pgpmime-version parameter for application/pgp-signature.)  This
approach is, I think, symmetric if we will decide Version: in
application/pgp-encrypted.

> > This is true only when we use the PGP program only. At
> > the last meeting, three people raised their hands to tell
> > implementation of OpenPGP. One of them is GNUPG, I
> > believe. We should be very careful to design PGP/MIME
> > nowadays.
> 
> There is no problem with different implementations - all
> of them should support the same message format (namely,
> OpenPGP).  Command line interfaces and similar issues are
> outside of the scope of this discussion.

I have not discussed command line interface issue. My point is that
implementors are free of how to implement PGP/MIME if it is
conformable to the spec.

I seemds that you assume that MUA interacts underlying a
PGP-conformable program. But it's ok that MUA itself has an ability to
produce PGP format. 

Explanation that everything is fine if you use PGP or GNUPG is not
appealing to me.

Again, my point is that we should be very careful when design PGP/MIME
based on PGP 5. We should not say that it's ok becase the PGP program
can handle it correctly.

> > Yes. But I'm very suspicious that this parameter useful.
> > Anyway, such discussion is not for PGP/MIME but for
> > architecture of security
> 
> Could you please elaborate?  This parameter is as clear as
> the signature block, and it repeats information present
> inside this signature block.

Maybe you may misunderstand my point. You proposed new values. It's
great. Thanks.

What I wanted to say is that the parameter itself seems less useful
than we expected. The micalg parameter is defined with the hope that
it is useful for one pass verification. But I don't know any
implementations use it.

Since future implementations may make use of this parameter, I'm not
particular to this topic.

But again, if micalg is really meaningless, we should feedback this to
RFC 1847.

> Additionally, Kazu gave the following list of problems:
> 
> > (1) version control
> 
> > (1.1) PGP packet format changed. Should we label
> > "Version: 2" for multipart/encrypted?
> 
> > (1.2) How about multipart/signed? Actually, the armor
> > format for detached signatures changed.
> 
> > (1.3) What kind of actions should be taken for each
> > version?  Is it OK for OpenPGP/MIME MUA to ignore
> > PGP/MIME messages?
> 
> > (1.4) If mismatch happens between the micalg parameter
> > and PGP signature, what should we do?
> 
> The old PGP format is a proper subset of the new one, so
> MUA and crypto software which handle OpenPGP properly will
> at least be able to properly decrypt and verify material
> generated by old PGP versions.

It's nice if RFC2015 aware (but not aware to PGP/MIME based on PGP 5)
program can skip further processing according to Version: 2.

And if your observations are correct, it means that many defined
parameber of RFC 2015 is meaningless.

> > (2) Conformance
> 
> > (2.1) What kinds of algorithm (for symmetric crypt,
> > asymmetric crypt, hash) is preferred when generated?
> 
> > (2.2) What is the relationship between *preferred xxx
> > algorithm* in PGP signature for each user and the
> > conformance of (2.1)?
> 
> > (2.3) What kind of actions should be taken if MUA
> > receives unrecognized PGP packets?
> 
> > (2.4) Generating: what kind of content-type must MUA be
> > able to generate? If MUA can sign only text/plain, is it
> > conformable?
> 
> > (2.5) Accepting: what kind of content-type must MUA be
> > able to handle? If MUA can't verify signed text/plain
> > under multipart/mixed, is it conformable?
> 
> This is not an issue of the message format proper, IMHO.
> Anyways, such MUAs are either crippled (2.4) or simply
> unable to handle conforming messages (2.5).

This is not a format issue but a standardization issue. Thus certainly
protocol issue. Recently, many other protocols define minimum
conformant set for generating and accepting.

> > (3) Others
> 
> > (3.1) Some people want to encode PGP signature and/or
> > encrypted message with MIME encoding(e.g not PGP armor
> > but base64). Should we allow this?
> 
> I don't see any benefits from this. 

And I don't see any benefits of PGP armor when used to encode detached
signatures. Note I can see benefits of PGP armor when used to encode
encrypted message for backward compatibility.

>  On the other hand,
> this would break existing software which relies on the
> content-transfer-encoding restrictions in RFC 2015. =>
> Don't do this.

Maybe. Bute many implementation of PGP/MIME can handle it
(e.g. encoded signature with base64), I guess. At least, my
implementation can do it though it is not my intention.

> > (4.1) Why not text/pgp?
> 
> > (4.2) S/MIME doesn't use multipart/encrypted. Why does
> > PGP/MIME?
> 
> I guess this should rather go to news.answers.

No. RFC is the best place to answer any technical questions. And if
such observations will be included in the new PGP/MIME RFC, the same
discussion will never repeat.

> > Is it practical? Who has implemented such complex
> > mechanism?
> 
> It has been done.  Just parse the message/rfc822
> attachment, go through the attachment tree, adjust the
> leafs' encodings, set the nodes' (multipart/*, message/*)
> encodings to 7bit and write the whole thing to disk.  

Great. Mutt can encode, for instance, a message, to be attached then
signed, which contains multipart whose second part is 8bit text, to
7bit? How about very recursed messages?

> Not too beautiful, but feasible.

Interesting. You are the first European for me to accept RFC 1847's
7bit restriction. :-)

I'm not a European and I don't use 8bit charset usually. Nonetheless,
I disagree with RFC 1847's 7bit restriction. The world is really
coming back to 8bit transportation while 7bit transportation spread in
the beginning of the MIME days.

> > (5.2) No RFC says that the protocol paramter is
> > case-insensitive.
> 
> So it isn't.  Where's the problem here?

MIME clearly defines any MIME parameters are case-*sensitive* if it is
not defined so. And RFC 1847 doesn't say the protocol parameter is
case-insensitive.

--Kazu

To: [email-masked]
Subject: Re: language tag
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Fri, 04 Sep 1998 06:27:44 +0900
Lines: 28
Sender: [email-masked]

From: Jon Callas <[email-masked]>
Subject: Re: language tag
Date: Thu, 03 Sep 1998 11:37:22 -0700

> Kazu, does the wording on the "Charset:" header help you? 

Yes. The 07 draft looks very reasonable to me. Thank you.

> Putting a tag in
> there to specify language is something simple that the implementor can do
> to solve this problem. The only other place where there is text is in the
> user id packets, and those are defined to have essentially no format. By 
> convention they are RFC822 names, but they can be X.500 names or anything
> else. It's reasonable to qualify a name with a RFC1766 language tag there
> if you don't want to use romaji.

As Paul answered, language tag is not necessary to be defined. 

It is necessary only for UTF-8 (namely Unicode) to distinguish
CKJ. And self-taging mechanism for UTF-8 is on the table. 

If a character set other than UTF-8 is used, the Charset: header is
enough.

Again, thank you for your revisions.

--Kazu

Date: Thu, 3 Sep 1998 17:54:15 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: language tag
Sender: [email-masked]

>>>>> "Jon" == Jon Callas <[email-masked]> writes:
>.... Does anyone else have an opinion anout the words
> "human-readable"?

I think "human readable" means readable by some humans, once the
collections of electrons in memory are converted to patterns of light
and dark on a display device.  Nothing in a computer is human-readable 
without transducers.  But once you have a transducer, UTF-8 is
human-readable whether it contains USASCII or CJK characters.

	paul

Date: Thu, 03 Sep 1998 13:52:46 -0700
To: Paul Hoffman / IMC <[email-masked]>, Jon Callas <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: language tag
Sender: [email-masked]

At 01:33 PM 9/3/98 -0700, Paul Hoffman / IMC wrote:

   No, it is *not* reasonable to use an RFC1766 tag there since there is
   nothing to differentiate the tag from the body. Inline tagging as specified
   in the new draft clearly differentiates what is a language tag from the
   content. It also allows more than one language tag per string, which is
   something that some Asians need if their two names are from different
   languages.

Great. I love not making changes.
   
   I don't think any change is needed. Freel free to take out the
   "human-readable" thing above, but leaving it in won't cause undue damage.
   
I've already started a -08 draft, on the off chance it's needed. The only
things in it are Ulf Moeller's implementation note, and adding an L to all
the constants in the CRC sample code. Does anyone else have an opinion
anout the words "human-readable"?

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Thu, 03 Sep 1998 13:33:18 -0700
To: Jon Callas <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: language tag
Sender: [email-masked]

At 11:37 AM 9/3/98 -0700, Jon Callas wrote:
>Ummm, I'm not sure I understand. My reading of printing UTF-8 in human
>readable form means that you should apply whatever print transform is
>needed to make it look like text.

Ah, I see what you're saying. Yes, then UTF-8 is "human-readable" in the
same sense that hexadecimal is human-readable. I thought you meant "a
normal human could look at this string and read it", which is not true for
UTF-8 (or hex...).

>The only other place where there is text is in the
>user id packets, and those are defined to have essentially no format. By
>convention they are RFC822 names, but they can be X.500 names or anything
>else. It's reasonable to qualify a name with a RFC1766 language tag there
>if you don't want to use romaji.

No, it is *not* reasonable to use an RFC1766 tag there since there is
nothing to differentiate the tag from the body. Inline tagging as specified
in the new draft clearly differentiates what is a language tag from the
content. It also allows more than one language tag per string, which is
something that some Asians need if their two names are from different
languages.

>I'm willing to put something quick in for IETF last call if it will solve
>the problem. I'm willing to say, "we do it the way they do it" for some
>suitable they. But I don't want to stop progress.

I don't think any change is needed. Freel free to take out the
"human-readable" thing above, but leaving it in won't cause undue damage.

--Paul Hoffman, Director
--Internet Mail Consortium

To: [email-masked]
Subject: Re: language tag
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Fri, 04 Sep 1998 03:09:32 +0900
Lines: 14
Sender: [email-masked]

From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: language tag
Date: Thu, 03 Sep 1998 09:42:54 -0700

> >draft-ietf-openpgp-formats-06.txt defines UTF-8 for each field of PGP
> >packets. Unfortunately, I couldn't find any method to identify
> >language. 
> 
> Please take a look at draft-whistler-plane14, which is in IESG last call.
> It specifies a way to identify languages within UTF-8.

This answers my question. Thanks!

--Kazu

Date: Thu, 3 Sep 1998 20:37:20 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Revising RFC 2015
Mail-Followup-To: [email-masked]
Sender: [email-masked]

This message has been compiled from some private
communications between Kazu Yamamoto, Michael Elkins, John
Noerenberg and myself on the topic of a revision of RFC
2015 ("MIME Security with Pretty Good Privacy (PGP)").  I
have slightly edited the messages; omissions include
consensus on issues being on or off topic and off topic
issues.

Please comment.

tlr

[Begin of old communications.]

I compiled the following list of issues (this is not the
original version; I've added some points):

>- RFC 2015 requires a micalg parameter when producing
>  "multipart/signed; protocol=application/pgp-signature"
>  body parts.  RFC 2015 defines the two hash algorithms
>  pgp-md5 and pgp-sha1, while the current OpenPGP draft
>  knows about some more algorithms (section 9.4).

>- If I understand draft-ietf-openpgp-formats-06 correctly,
>  OpenPGP permits parallel signatures with different hash
>  algorithms applying to one and the same message.  We may
>  wish to permit a comma-separated list of hash algorithms
>  for the micalg parameter.

>  Further pursuing this direction of thought, one may be
>  inclined to permit several application/pgp-signature
>  body parts in a multipart/encrypted attachment, each of
>  them corresponding to a specific micalg.  This micalg
>  parameter should additionally be listed in the
>  Content-Type header of said additional signature parts.

[This one was not in the first version:]

>- We may wish to require another parameter with the
>  application/pgp-signature body parts, namely, "pkalg".
>  This parameter would identify the public key algorithm
>  used to generate the signature, e.g., rsa, elgamal, dsa,
>  etc.

>  The rationale behind this is that mail user agents may
>  wish to invoke different external OpenPGP
>  implementations to verify different kinds of signatures
>  - e.g., pgp 2 for RSA/MD5, pgp 5 for DSA/SHA1, and gpg
>  for RSA/RMD160, RSA/SHA1, and so forth.

[Original list continued.]

>- Section 6.2 of RFC 2015 explicitly mentions PGP 2.x. We
>  may wish to update this to reference the OpenPGP RFC
>  when it comes out - but that's just a nit.

>- RFC 2015 does not explicitly specify what type of PGP
>  signature is to be generated when signing messages
>  (binary document or text document signature).  But
>  that's pretty much a non-problem since the RFC
>  _requires_ user agents to convert texts to canonical
>  format before verifying or generating signatures, thus
>  making text and binary signatures of the message body
>  equivalent.

Kazu's reply to this plus my comments:

>> From the MUA's point of view, pgp 2, pgp 5, and gpg
>> behave pretty much the same way.

> This is true only when we use the PGP program only. At
> the last meeting, three people raised their hands to tell
> implementation of OpenPGP. One of them is GNUPG, I
> believe. We should be very careful to design PGP/MIME
> nowadays.

There is no problem with different implementations - all
of them should support the same message format (namely,
OpenPGP).  Command line interfaces and similar issues are
outside of the scope of this discussion.

[micalg parameter for multipart/signed]

> Yes. But I'm very suspicious that this parameter useful.
> Anyway, such discussion is not for PGP/MIME but for
> architecture of security

Could you please elaborate?  This parameter is as clear as
the signature block, and it repeats information present
inside this signature block.

[binary vs. text signatures]

> Here here here. Some PGP/MIME implementors repeatedly
> asked me this topic. As Thomas said, RFC 2015 is enough.
> But I think it's not readable. It's nice if the next
> PGP/MIME draft will include binary vs text packet format
> discussions. I'm sick of answering this question.

Additionally, Kazu gave the following list of problems:

> (1) version control

> (1.1) PGP packet format changed. Should we label
> "Version: 2" for multipart/encrypted?

> (1.2) How about multipart/signed? Actually, the armor
> format for detached signatures changed.

> (1.3) What kind of actions should be taken for each
> version?  Is it OK for OpenPGP/MIME MUA to ignore
> PGP/MIME messages?

> (1.4) If mismatch happens between the micalg parameter
> and PGP signature, what should we do?

The old PGP format is a proper subset of the new one, so
MUA and crypto software which handle OpenPGP properly will
at least be able to properly decrypt and verify material
generated by old PGP versions.

> (2) Conformance

> (2.1) What kinds of algorithm (for symmetric crypt,
> asymmetric crypt, hash) is preferred when generated?

> (2.2) What is the relationship between *preferred xxx
> algorithm* in PGP signature for each user and the
> conformance of (2.1)?

> (2.3) What kind of actions should be taken if MUA
> receives unrecognized PGP packets?

> (2.4) Generating: what kind of content-type must MUA be
> able to generate? If MUA can sign only text/plain, is it
> conformable?

> (2.5) Accepting: what kind of content-type must MUA be
> able to handle? If MUA can't verify signed text/plain
> under multipart/mixed, is it conformable?

This is not an issue of the message format proper, IMHO.
Anyways, such MUAs are either crippled (2.4) or simply
unable to handle conforming messages (2.5).

> (3) Others

> (3.1) Some people want to encode PGP signature and/or
> encrypted message with MIME encoding(e.g not PGP armor
> but base64). Should we allow this?

I don't see any benefits from this.  On the other hand,
this would break existing software which relies on the
content-transfer-encoding restrictions in RFC 2015. =>
Don't do this.

> (4) FAQ

> (4.1) Why not text/pgp?

> (4.2) S/MIME doesn't use multipart/encrypted. Why does
> PGP/MIME?

I guess this should rather go to news.answers.

> (5) security multipart issue (maybe should feedback to
> RFC 1847)

> (5.1) In many cases, European people exchange their
> Latin-1 messages with CTE: 8bit. But RFC 1847 requires
> objects to be signed be 7bit. How can sign 8bit
> message/rfc822? Ned said that MUA must change 8bit
> message to 7bit. 

Precisely.

> Is it practical? Who has implemented such complex
> mechanism?

It has been done.  Just parse the message/rfc822
attachment, go through the attachment tree, adjust the
leafs' encodings, set the nodes' (multipart/*, message/*)
encodings to 7bit and write the whole thing to disk.  Not
too beautiful, but feasible.

> (5.2) No RFC says that the protocol paramter is
> case-insensitive.

So it isn't.  Where's the problem here?

[End of old communications.]

-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

Date: Thu, 03 Sep 1998 11:37:22 -0700
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: language tag
Sender: [email-masked]

At 09:42 AM 9/3/98 -0700, Paul Hoffman / IMC wrote:

   A note to the editors: I found a problem relating to this in reading the
   -07 draft. In 5.2.3.22, you say "in human-readable form (UTF-8)". UTF-8 is
   not human-readable unless every character in the text is US-ASCII. During
   IESG last cally, you should probably strike "in human-readable form" from
   this section.
   
Ummm, I'm not sure I understand. My reading of printing UTF-8 in human
readable form means that you should apply whatever print transform is
needed to make it look like text. It's just as applicable to ASCII as UTF-8
(and in fact that text dates from the days when the spec said ASCII). For
example, 0x4a6f6e407067702e636f6d is the ASCII representation of my return
mail address, but it's less human readable than "[email-masked]" is. If I put
on my spec-lawyer hat and strike "in human-readble form" then it's
acceptable to put the UTF-8 out in hex or ISO-Latin5, even. "Human-readable
form" means to me that you put the bits through whatever transform makes
the right glyphs come out, and that's precisely what we want; it's an
admonition not to eat the daisies. But I'll strike it if that's what gets
us passed.

Kazu, does the wording on the "Charset:" header help you? Putting a tag in
there to specify language is something simple that the implementor can do
to solve this problem. The only other place where there is text is in the
user id packets, and those are defined to have essentially no format. By
convention they are RFC822 names, but they can be X.500 names or anything
else. It's reasonable to qualify a name with a RFC1766 language tag there
if you don't want to use romaji.

I'm willing to put something quick in for IETF last call if it will solve
the problem. I'm willing to say, "we do it the way they do it" for some
suitable they. But I don't want to stop progress.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Thu, 3 Sep 1998 14:26:39 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: [email-masked]
cc: Tony Mione <[email-masked]>
Subject: Request for updates or new submissions to the PGP implemtation web page
Sender: [email-masked]

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

It has been some time since I have updated my PGP implementation survey
page. If you have written a package that supports PGP based object
encryption, please fill out a survey form and email it to may so I may add
that product to the web page. If you have filled out a survey but your
product has new features, please send any changes or amendments and they
will be reflected on the page. To find a blank survey form and the
implementation page as it currently stands, go to:

http://www-ns.rutgers.edu/~mione/openpgp/

Currently, the following products are listed on the page:

Cryptix
Mew
Privtool
pgp.el
MailCat
NoCeM
PGP 2.6.3in
PGPin
Cryptlib
Decrypt
Potato
Jack B. Nymble
Information Heap
PGPlib
Mapil
E-Secure
OPGP (formerly Ciphercopia)
G10
PGPsdk (also PGP 5.5 from NAI)

Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[email-masked]                 W3: http://www-ns.rutgers.edu/~mione/
PGPFP:E2252CCD28733C5B  0B918A4E22BAFA9F       ***** Important: John 17:3 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR

Date: Thu, 3 Sep 1998 14:17:38 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: [email-masked]
cc: Tony Mione <[email-masked]>
Subject: Call for Laundry List
Sender: [email-masked]

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

At the IETF OpenPGP WG meeting last week, it was announced that the formats
draft (draft-ietf-openpgp-formats-07.txt) will be going to the IESG
shortly. Since many items were put off as too complex to hash out during
the deliberations involved in writing this document, it was thought that
once this is published as an rfc, the OpenPGP Working Group should start
working on the next version of the document. That version will include all
the really cool features that we didn't have time to do in the first pass.
For instance, one idea that came up was to include an 'alternate user id'
and allow varying data types including gif or jpg images of the key owner.

I have been tasked with gathering the 'Laundry List' of issues we would
like to revisit as a group. I am requesting that if you voiced an idea that
got 'put off until the next version of OpenPGP' sometime since the OpenPGP
working group formed, please send a brief description of those ideas either
directly to me. I will gather the ideas into a list and post that list to
the ietf-open-pgp mailing list in about one months time. I would like to
close the period for submissions around October 1st. I will be willing to
take ideas for a short time after that, they just will not be in the first
list sent to the working group.

I may also post the list on my web page. If I do that, I will announce the
url to the list as well.

Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[email-masked]                 W3: http://www-ns.rutgers.edu/~mione/
PGPFP:E2252CCD28733C5B  0B918A4E22BAFA9F       ***** Important: John 17:3 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR

Date: Thu, 03 Sep 1998 09:42:54 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: language tag
Sender: [email-masked]

At 07:44 PM 9/3/98 +0900, =?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?= wrote:
>draft-ietf-openpgp-formats-06.txt defines UTF-8 for each field of PGP
>packets. Unfortunately, I couldn't find any method to identify
>language. 

Please take a look at draft-whistler-plane14, which is in IESG last call.
It specifies a way to identify languages within UTF-8.

>RFC 2266 suggests that language tag defined in RFC 1766 should be
>provided in each protocols. Please define RFC 1766-like means to
>specify language.

This is not possible. The text chunks in OpenPGP are not MIME chunks, they
are bare strings. You have to use inline language tagging, as specified in
draft-whistler-plane14.

A note to the editors: I found a problem relating to this in reading the
-07 draft. In 5.2.3.22, you say "in human-readable form (UTF-8)". UTF-8 is
not human-readable unless every character in the text is US-ASCII. During
IESG last cally, you should probably strike "in human-readable form" from
this section.

--Paul Hoffman, Director
--Internet Mail Consortium

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-formats-07.txt
Date: Thu, 03 Sep 1998 10:49:00 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy 
Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, L. Donnerhacke, H. Finney, R. Thayer
	Filename	: draft-ietf-openpgp-formats-07.txt
	Pages		: 59
	Date		: 02-Sep-98
	
   This document is maintained in order to publish all necessary
   information needed to develop interoperable applications based on
   the OpenPGP format. It is not a step-by-step cookbook for writing an
   application. It describes only the format and methods needed to
   read, check, generate, and write conforming packets crossing any
   network. It does not deal with storage and implementation questions.
   It does, however, discuss implementation issues necessary to avoid
   security flaws.
 
   Open-PGP software uses a combination of strong public-key and
   symmetric cryptography to provide security services for electronic
   communications and data storage.  These services include
   confidentiality, key management, authentication, and digital
   signatures. This document specifies the message formats used in
   OpenPGP.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-formats-07.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-openpgp-formats-07.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-formats-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-formats-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-formats-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Subject: language tag
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Thu, 03 Sep 1998 19:44:07 +0900
Lines: 12
Sender: [email-masked]

draft-ietf-openpgp-formats-06.txt defines UTF-8 for each field of PGP
packets. Unfortunately, I couldn't find any method to identify
language. 

RFC 2266 suggests that language tag defined in RFC 1766 should be
provided in each protocols. Please define RFC 1766-like means to
specify language.

Otherwise, we can't distinguish Japanese/Korean/Chinese.

--Kazu

Date: Tue, 01 Sep 1998 11:10:54 -0700
To: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?= ), [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: comments on the format 06 draft
Sender: [email-masked]

At 01:18 AM 9/1/98 +0200, Ulf Möller wrote:
   Are there going to be more revisions of the draft?

The -07 draft is at the editor's desk, you should see their note here today
or tomorrow. This is the draft that's going to the IESG. I slipped in the
correction to the CRC calculation, and made some changes for Kazu with
regard to character set.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 1 Sep 1998 10:41:56 -0400
From: [email-masked]
To: Ulf =?iso-8859-1?Q?M=F6ller?= <[email-masked]>
cc: [email-masked]
Subject: Re: comments on the format 06 draft
Sender: [email-masked]

On Mon, 31 Aug 1998, Ulf [iso-8859-1] Möller wrote:

> BTW, why do clear-signed messages have a "Hash:" header? The hash
> algorithm is given in the signature packet.

So that you can start hashing as you process the message.  When there was
only one hash, it didn't matter.  Now you would need to do several hashes
if you wanted to process it as a filter so you would be ready when you
hit the signatures.  Otherwise you need to know which hashes to use in
advance (the logic behind the one-pass signature header).

(Note that the spec might not be clear, but if two signatures are
appended, one with MD5 and one with SHA1, both must be specified in the
Hash: header.  No Hash: header implies MD5, but any Hash: header implies
the list is complete).