Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)

["Bob Jueneman" <[e-mail]>]

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 <[e-mail]> 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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01868 for ietf-smime-bks; Wed, 30 Sep 1998 13:26:00 -0700 (PDT)
Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA01857; Wed, 30 Sep 1998 13:23:50 -0700 (PDT)
Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Wed, 30 Sep 1998 14:30:02 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 30 Sep 1998 14:29:51 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id NAA01858
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00344 for ietf-smime-bks; Tue, 29 Sep 1998 11:19:48 -0700 (PDT)
Received: from aisle (aisle.tesco.net [194.73.73.167]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA00340 for <[e-mail]>; Tue, 29 Sep 1998 11:19:45 -0700 (PDT)
Received: from harter [62.172.24.232]  by aisle with smtp (Exim 1.70 #1) id 0zO4T8-0005tG-00; Tue, 29 Sep 1998 19:25:51 +0100
Message-ID: <000c01bdebde$f82b5b60$e818ac3e@harter>
From: "Darren Harter" <[e-mail]>
To: "Adam Back" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Date: Tue, 29 Sep 1998 19:25:49 -0000
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

Adam,

The references you quote for CASM are extremely out of date.  First,  CASM
does not have anything to do with PKI issues as you URL suggests.  CASM's
sister project CLOUD COVER (members of which play an active part on the PKIX
working group) does that.  Secondly,  the CASM team are actively
participating openly and positively in this working group, and the CASM
architecture is compliant with the current draft specs.  Thirdly, DERA have
had NO involvement with developing the CASM Architecture.  Finally, CASM is
not a protocol. It is an architecture that supports multiple security
protocols and key management schemes in a flexible yet standardised way.

If you require more up to date information regarding CASM or CLOUD COVER, I
suggest you contact CESG direct.  See www.cesg.gov.uk for contact
information.

Regards,

Darren Harter
CASM Applications Development Manager,
CASM Programme Office
CESG
Work: [e-mail]
Home: [e-mail], or [e-mail], or
[e-mail]


-----Original Message-----
From: Adam Back <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail]
<[e-mail]>
Date: Monday, September 28, 1998 06:54
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers
in S/MIME or PGP/MIME messages)


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





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA27105 for ietf-smime-bks; Tue, 29 Sep 1998 00:50:20 -0700 (PDT)
Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA27094 for <[e-mail]>; Tue, 29 Sep 1998 00:50:18 -0700 (PDT)
Received: (qmail 9083 invoked from network); 29 Sep 1998 07:57:03 -0000
Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 29 Sep 1998 07:57:03 -0000
Received: (qmail 3117 invoked from network); 29 Sep 1998 07:57:03 -0000
Received: from wottoway.eris.dera.gov.uk (HELO wottaway.eris.dera.gov.uk) (128.98.10.17) by mail-relay.eris.dera.gov.uk with SMTP; 29 Sep 1998 07:57:03 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 29 Sep 1998 08:56:36 +0100
To: Adam Back <[e-mail]>
From: William Ottaway <[e-mail]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822  headers in S/MIME or PGP/MIME messages)
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA05203 for ietf-smime-bks; Mon, 28 Sep 1998 10:42:02 -0700 (PDT)
Received: from exeter.ac.uk (hermes.ex.ac.uk [144.173.6.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA05199; Mon, 28 Sep 1998 10:41:53 -0700 (PDT)
Received: from dialup18 [144.173.6.218] by hermes via ESMTP (SAA21993); Mon, 28 Sep 1998 18:48:43 +0100 (BST)
Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id SAA18304; Mon, 28 Sep 1998 18:48:06 +0100
Date: Mon, 28 Sep 1998 18:48:06 +0100
Message-Id: <[e-mail]>
From: Adam Back <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
In-reply-to: <[e-mail]> (message from William Ottaway on Mon, 28 Sep 1998 17:00:48 +0100)
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA04111 for ietf-smime-bks; Mon, 28 Sep 1998 08:54:33 -0700 (PDT)
Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA04104 for <[e-mail]>; Mon, 28 Sep 1998 08:54:31 -0700 (PDT)
Received: (qmail 21326 invoked from network); 28 Sep 1998 16:01:16 -0000
Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 28 Sep 1998 16:01:16 -0000
Received: (qmail 22588 invoked from network); 28 Sep 1998 16:01:16 -0000
Received: from wottoway.eris.dera.gov.uk (HELO wottaway.eris.dera.gov.uk) (128.98.10.17) by mail-relay.eris.dera.gov.uk with SMTP; 28 Sep 1998 16:01:16 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 28 Sep 1998 17:00:48 +0100
To: "William H. Geiger III" <[e-mail]>, "Blake Ramsdell" <[e-mail]>
From: William Ottaway <[e-mail]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Cc: "Steve Hole" <[e-mail]>, "Ned Freed" <[e-mail]>, <[e-mail]>, <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 16:00 25/09/98 -0500, William H. Geiger III wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>In <[e-mail]>, on 09/25/98 
>   at 01:47 PM, "Blake Ramsdell" <[e-mail]> said:
>
>>> -----Original Message-----
>>> From: William H. Geiger III [mailto:[e-mail]]
>>> Sent: Friday, September 25, 1998 1:22 PM
>>> To: Steve Hole
>>> Cc: Ned Freed; [e-mail]; [e-mail]
>>> Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
>>> 
>>> In <[e-mail]>, on 09/18/98 
>>>    at 10:55 AM, Steve Hole <[e-mail]> 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: [phone]
DERA Malvern,                Fax: [phone]
St. Andrews Road,            email: [e-mail]
Malvern,
Worcs,
WR14 3PS



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA04077 for ietf-smime-bks; Mon, 28 Sep 1998 08:52:18 -0700 (PDT)
Received: from firewall.globeset.com ([e-mail] [207.239.133.67]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA04073 for <[e-mail]>; Mon, 28 Sep 1998 08:52:13 -0700 (PDT)
Received: from drought.globeset.com ([e-mail] [10.1.192.39]) by firewall.globeset.com (8.9.1a/8.9.1) with ESMTP id KAA20330; Mon, 28 Sep 1998 10:58:56 -0500 (CDT)
Received: (from trevor@localhost) by drought.globeset.com (8.7.6/8.7.3) id KAA28679; Mon, 28 Sep 1998 10:58:56 -0500
From: Trevor Sosebee <[e-mail]>
Date: Mon, 28 Sep 1998 10:58:56 -0500 (CDT)
To: Russ Housley <[e-mail]>
Cc: Trevor Sosebee <[e-mail]>, [e-mail], [e-mail]
Subject: Re: AuthenticatedData in CMS
In-Reply-To: <[e-mail]>
References: <13817.29486.978819.823635@drought> <[e-mail]>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13839.45374.39196.586726@drought>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Russ,

The scenario I had envisioned here was one in which the sender had no
certificates just an out of band authentication token from the
recipient, but no other information about the recipient.

After multiple emails with Brian Korver, the solution seemed to be to
use AuthenticatedData with the authentication token carried in a
MailListRecipientInfo.

Trevor

Russ Housley writes:
 > Trevor:
 > 
 > Why not use signed-data in this case?
 > 
 > When using a MAC, authentication is lost if the key is disclosed.
 > 
 > Russ
 > 
 > At 02:02 PM 9/11/98 -0500, Trevor Sosebee wrote:
 > >Suppose an entity wants to use an AuthenticatedData structure as a
 > >generic way to carry authenticated data, and does not care who the
 > >recipient is or has no knowledge of the recipient's credentials at the 
 > >time of creation. It seems there should be a way to do this with no
 > >such knowledge, but since RecipientInfos is required to exist and contain
 > >at least one RecipientInfo, there seems to be no way around the problem.
 > >
 > >At the very least could the requirement that RecipientInfos be present 
 > >be relaxed to possibly contain no RecipientInfo?
 > >
 > >Trevor
 > >
 > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA04001 for ietf-smime-bks; Mon, 28 Sep 1998 08:40:50 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA03997 for <[e-mail]>; Mon, 28 Sep 1998 08:40:49 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id IAA02299; Mon, 28 Sep 1998 08:45:59 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Mon, 28 Sep 1998 11:38:32 -0400
To: Trevor Sosebee <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: AuthenticatedData in CMS
Cc: [e-mail], [e-mail]
In-Reply-To: <13817.29486.978819.823635@drought>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Trevor:

Why not use signed-data in this case?

When using a MAC, authentication is lost if the key is disclosed.

Russ

At 02:02 PM 9/11/98 -0500, Trevor Sosebee wrote:
>Suppose an entity wants to use an AuthenticatedData structure as a
>generic way to carry authenticated data, and does not care who the
>recipient is or has no knowledge of the recipient's credentials at the 
>time of creation. It seems there should be a way to do this with no
>such knowledge, but since RecipientInfos is required to exist and contain
>at least one RecipientInfo, there seems to be no way around the problem.
>
>At the very least could the requirement that RecipientInfos be present 
>be relaxed to possibly contain no RecipientInfo?
>
>Trevor
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA02865 for ietf-smime-bks; Mon, 28 Sep 1998 06:12:37 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA02860 for <[e-mail]>; Mon, 28 Sep 1998 06:12:34 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id JAA16245 for <[e-mail]>; Mon, 28 Sep 1998 09:23:09 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id JAA00651; Mon, 28 Sep 1998 09:21:39 -0400
Date: Mon, 28 Sep 1998 09:21:39 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: 8/26/98 S/MIME WG Minutes
Sender: [e-mail]
Precedence: bulk

All,

These are the minutes (revised to include Denis Pinkas' 28 Sep 98
comment) that I sent to [e-mail].

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

This message includes the minutes of the IETF S/MIME Working Group
(WG) meeting held on 26 August 1998 in Chicago, IL, USA. These minutes 
were coordinated with the S/MIME WG mail list members.  All briefing 
slides are stored at: ftp://ftp.ietf.org/ietf/smime/.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Introductions - Russ Housley
 
Russ reviewed the agenda.  Nobody objected to the agenda.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

MSG Draft Discussion - Blake Ramsdell

Blake stated that the 6 Aug 98 S/MIME v3 Message Specification (MSG)
Internet Draft (I-D) includes the comments submitted to the S/MIME WG mail
list.  He  stated that the application/MIME text was deleted from MSG and
the X.509 references were changed to PKIX references.  When asked if there
were any other comments to the MSG I-D, the room was silent.  When asked how
many people had read the MSG I-D, not many in the room raised their hands.
Blake stated that the MSG I-D has been submitted for last call within the
S/MIME WG and that there are no other changes planned for the MSG I-D. 
 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CERT Draft Discussion - Blake Ramsdell

Blake stated that the 6 Aug 98 S/MIME v3 Certificate Handling (CERT) I-D
includes the comments submitted to the S/MIME WG mail list.  He stated that
the CERT I-D has been submitted for last call within the S/MIME WG.  When
asked how many people had read the CERT I-D, not many in the room raised
their hands.  Blake stated that the X.509 references were changed to PKIX
references.  There was a comment from an attendee that Section 3.2 "Required
Name Attributes" should be deleted because it is redundant to the PKIX X.509
Certificate and CRL Profile (PKIX Part I).  Nobody objected to this change.
There was a comment from an attendee who was concerned that certificates
included in S/MIME messages may divulge sensitive information.  The
consensus of the attendees was that this is a matter to be solved by the
policy of the local organization of the user who is releasing the S/MIME
message.  The group decided that no change is required in the S/MIME I-Ds
regarding this issue.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

ESS Draft Discussion - Paul Hoffman

Paul stated that the 5 Aug 98 Enhanced Security Services for SMIME (ESS) I-D
has been submitted for last call within the S/MIME WG.  When asked how many
people had read the ESS I-D, not many in the room raised their hands.  Paul
stated that the EntityIdentifier syntax needs to be added to the ESS I-D
ASN.1 module as noted on the S/MIME WG mail list.  He stated that the S/MIME
ASN.1 modules need to be compiled by various ASN.1 toolkits to determine if
there are any other discrepancies.  Van Dyke and Associates (VDA)
volunteered to compile the ESS and CMS I-D ASN.1 modules using the SNACC
ASN.1 compiler, but others were urged to check the ASN.1 with their own
compilers as well.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CMS Draft Discussion - Russ Housley

Russ presented briefing slides (see ftp://ftp.ietf.org/ietf/smime/)
regarding the open issues related to the June 98 Cryptographic Message
Syntax (CMS) I-D.  Russ stated that the ESS, CERT and MSG I-Ds are dependent
on the CMS I-D; therefore, those I-Ds will not complete WG Last Call until
the CMS I-D completes WG Last Call.  When CMS enters WG Last Call, then all
of the I-Ds will be final after the two-week last call period is complete.
In summary, the WG last call period will simultaneously close for the CMS,
ESS, CERT and MSG I-Ds. 


Slide #1: CMS Document Status:  All CMS sections are complete except for
Section 12 that will document the mandatory algorithms and some optional
algorithms.  The comments received on the mail list have been incorporated
into a CMS draft that has not yet been released to the WG.  A draft of
Section 12 was discussed on the mail list.  The most recent draft is
included in the 22 July message, subject: "CMS Section 12, take 3".  The
completion of Section 12 depends on the Diffie-Hellman (D-H) Key Agreement
Method I-D <draft-ietf-smime-x942-00.txt>.


Slide #2: Message Digest Algorithms: 

SHA-1 is mandatory to implement.  The AlgorithmIdentifier syntax includes an
optional parameters field.  There was some debate regarding whether the
parameters field should be absent or set to an ASN.1 NULL (05 00 hex) when
the SHA-1 OID is populated in the AlgorithmIdentifier syntax.  Eric Rescorla
and Blake pointed out that current implementations encode the field as an
ASN.1 NULL.  The attendees decided that the CMS I-D will state that the
parameters must be encoded as an ASN.1 NULL, but that CMS implementations
should be able to accept either an ASN.1 NULL or absent parameters.  This is
required for compatibility with S/MIME v2.     

MD5 is optional to implement.  The attendees decided that the CMS I-D will
state that the parameters must be encoded as an ASN.1 NULL when the MD5 OID
is populated in the AlgorithmIdentifier syntax.  This is required for
compatibility with S/MIME v2.     


Slide #3: Signature Algorithms:  

DSA-with-SHA1 is mandatory to implement.  The attendees decided that the CMS
I-D will state that the parameters must be absent (not ASN.1 NULL).  This is
required for consistency with PKIX Part I.

RSA-with-SHA1 and RSA-with-MD5 are optional to implement.  With both of
these combinations, the rsaEncryption OID must be used in the signedData
signerInfo signatureAlgorithm.  The digesting algorithm is indicated in the
signedData signerInfo digestAlgorithm.  The attendees decided that the CMS
I-D will state that the parameters must be encoded as an ASN.1 NULL when the
rsaEncryption OID is populated in the AlgorithmIdentifier syntax.  This is
required for compatibility with S/MIME v2.     


Slide #4: Key Management (KM) Algorithms: 

The group discussed which KM algorithms and key encryption algorithms should
be documented in CMS.  The attendees decided that the most important
algorithms to cover are the mandatory-to-implement algorithms.  The
attendees agreed that optional algorithms not already covered in CMS can be
documented in separate I-Ds. 

The proposed Section 12 text states that static D-H (as specified in the D-H
I-D) will be mandatory to implement.  CMS will document how static D-H can
be used to generate a key-encryption key (KEK) for use with Triple DES.  It
will also document how static D-H can be used to generate a KEK for use with
RC2. 

When obtaining the bits of the KEK, the minimal number of bits needed to
form the KEK must be used (a.k.a. key reduction).  There is an open issue
regarding how the minimal number of bits is obtained for RC2.  The group
decided that this issue will be debated on the list.

The group decided that CMS should not discuss the use of D-H to generate
keys for DES.  

The group decided that CMS should specify that at least 512 modulus should
be used.

An attendee asked about key recovery.  Russ stated that this issue has been
thoroughly discussed on the mail list and that discussion identified at
least three ways to implement key recovery without specifying a specific
strategy in CMS. 


Slide #5: Key Management (KM) Algorithms 2:  Mail List Key (MLK) encryption
is optional to implement.  CMS will discuss the use of Triple-DES and RC2 to
be used for MLK purposes.


Slide #6: Key Wrapping Algorithm:  CMS will document a single
mandatory-to-implement key wrapping strategy to be used with key agreement
and MLK (but not key transport).  Jim Schaad asked if an OID should be
defined to identify the wrapping algorithm.  Russ answered that the X9.42
D-H OID used in conjunction with CMS implies the wrapping algorithm.  John
Pawling pointed out that Sec 12.4, 3rd paragraph states: "Triple-DES may be
an exception here; the same identifier is used for both 2-key and 3-key
Triple DES.  This is probably easily handled by always wrapping three keys,
even if the first and third keys match."  John stated that these issues need
to be resolved to avoid interoperability problems. 

Slide #7: Content Encryption Algorithms:  Triple-DES in CBC mode is the
mandatory-to-implement algorithm.  The DES-EDE3-CBC OID will be used.   The
group decided that DES will not be documented in CMS. 


Slide #8: Content Encryption Algorithms 2: The group decided that CMS will
document RC2 in CBC mode as a "should" to implement (rather than "may").
The RC2-CBC OID will be used.

Slide #9: Message Authentication Code (MAC) Algorithms:  The group decided
by a clear majority that HMAC-with-SHA1 will be the mandatory-to-implement
algorithm.  The wording in CMS will be: "If authenticatedData is
implemented, then HMAC-with-SHA1 must be implemented."  The group also
decided that DES MAC will not be included in CMS as an optional algorithm.

Slide #10: Way Forward:  When Section 12 is completed, then CMS will be
ready for last call.  Russ asked if there were any other issues.

1) Denis Pinkas asked if there was a way to verify the "correctness" of a
CMS message.  Dennis considers signature generation time to be a critical
factor in determining whether or not that signature is valid.  If the
signing key is revoked, then the signing time would indicate if the message
signed before or after the revocation date.  John Pawling pointed out that
the MSG I-D already states that the signingTime attribute should always be
included in signed messages.  Denis said that he would send a message to 
the S/MIME WG mail list regarding this topic as a stimulus for further
debate.

2) Denis also was concerned that the serial number in the signer's cert is
not covered by the signedData signerInfo signature, so a different cert
could be substituted for the signer's cert.  Russ stated that the SIGATTR
I-D addresses this issue.

3) Doug Maughn asked about the processing requirements for generating a
countersignature.  It was proposed on the list that the generator of a
countersignature must validate the original signature before generating the
countersignature.  Russ has included that proposal in the CMS draft that he
has not yet published.  He stated that "validate" means verify the signature
value of the CMS signedData, not necessarily validate the signer's cert path.

4) John Linn proposed that text should be added to the Security
Considerations section regarding the use of PKCS #1 v2.  The group agreed
that this was a good idea.  John Linn agreed to provide the text for the
Security Considerations section of CMS.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

X9.42 Draft Discussion - Russ Housley

The D-H Key Agreement Method I-D (a.k.a. D-H I-D) is required before CMS can
progress to WG Last Call.  After the D-H I-D was published to the list, Russ
asked if there were any patents that applied to the D-H variant documented
in the I-D.  Certicom announced on the list that they have applied for a
patent that covers the variant of the D-H algorithm specified in the D-H
I-D.  He proposed two alternatives: 1) CMS and D-H I-Ds could continue to
mandate the current D-H variant; or 2) WG could pursue a different D-H
variant as the mandatory-to-implement KM algorithm to avoid the delay
associated with working out the licensing agreement with Certicom.

Russ presented a slide describing another variant.  The variant currently
documented in D-H I-D is called Static-Static (S-S) D-H.  With S-S D-H, the
originator has a static key and the recipient has a static key both of which
are contained in certificates.  The alternative is called Ephemeral-Static
(E-S) D-H.  With E-S D-H, the recipient has a static key contained in a
certificate, but the originator generates an ephemeral key not contained
within a certificate.  Russ stated that the E-S D-H would need to be
documented and then distributed to determine if there are any patents or
pending patents that apply to the E-S D-H variant.  He stated that the E-S
D-H has some of the same properties as the Open PGP D-H strategy, but not
identical.  Paul Hoffman noted that there have been no patent statements
made regarding the Open PGP D-H strategy. 

Russ presented the following info:

          S-S D-H              |         E-S D-H
-------------------------------|--------------------------------
Pending patent                 | No patents (?)
1 exponentiation per recipient | 2 exponentiations per recipient
Data origin authentication     | No authentication
Shorter certificate            | Longer certificate (p,q,g) 
			       | (about 200 bytes longer)
Originator cert in message     | Originator cert not in message
Common p,q,g parameters        | Use recipient's p,q,g values

The question was asked if q is really required to be transmitted in the CMS
heading.  Russ stated that q should be included so that the existing X9.42
ASN.1 syntax for the p,q,g parameters can be used.  Also, the q value can be
used to validate the p and g values.    

Darren Harter pointed out that there is another option in which the
originator would produce a self-signed E-S D-H cert and include it in the
message.

Tim Dierks from Consensus Development Corporation/Certicom spoke regarding
Certicom's pending patent that they believe covers the X9.42 D-H variant.
Tim stated that Certicom is willing to issue a royalty-free license to
S/MIME and PKIX vendors to use the technology covered by their pending
patent. Tim stated that any applicant must divulge their own patents and
pending patents that would block the implementation of the mandatory
requirements of PKIX or CMS.  Tim stated that Certicom will require that the
applicant issue a royalty-free license to Certicom covering the applicant's
patented technology.   Tim stated that Certicom intends to gain revenue for
use of the technology in "non-S/MIME" cases.

Eric Rescorla pointed out that the S/MIME WG's acceptance of this option
would limit future vendor's options.  He also pointed out that CMS is used
in applications other than S/MIME, so the Certicom's offer does not benefit
all users of CMS.

Paul pointed out that there is not an official definition of "S/MIME", so
the limitation to issue licenses to "S/MIME" vendors is problematic.  Paul
also pointed out that there will probably be future versions of the S/MIME
specifications.  Paul reiterated Eric's statement that CMS is used in
applications other than S/MIME.

Jeff Schiller, the IETF Security Are Co-Director, expressed his desire to
avoid a situation in which licenses must be obtained to implement
mandatory-to-implement features.  He was concerned with the restrictions
placed by Certicom's proposal regarding how CMS is to be used.  Jeff stated
that he had difficulty with the "S/MIME" limitation included in Certicom's
offer because not all CMS implementers would be able to obtain the
royalty-free license.  Jeff stated that he liked the E-S D-H option better
than the S-S D-H option due to technical reasons in addition to the patent
issues.  Jeff stated that he has found that the two exponentiations required
to be calculated for each recipient in the E-S D-H option is acceptable as
far as performance is concerned.

John Pawling pointed out that some vendors are implementing CMS/ESS security
libraries that could be used by "S/MIME" or "non-S/MIME" applications, so
this further complicates the issue.  He pointed out that the E-S option
eliminates the need to validate the originator's KM cert, so a significant
time saving is achieved.  He recommended that the WG should pursue both the
E-S D-H and S-S D-H options in parallel.  Several attendees agreed with this
plan.

Dave Solo pointed out that some environments consist of an "S/MIME"
application on one end of a transaction and a "non-S/MIME" application on
the other end.  Dave also asked if there was an issue with using the E-S D-H
option with forming a pairwise key with yourself.  Russ stated that that
there will not be a problem with that operation.

Tim stated that he would obtain more info from Certicom.  Later in the
meeting after talking with Certicom via telephone, Tim stated that Certicom
agreed to provide royalty-free licenses for all uses of CMS, not just for
use in "S/MIME" applications.  Tim stated that the license would also cover
the use of S-S D-H in future versions of the CMS and PKIX specifications
(not just S/MIME v3). 


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

SIGATTR Draft Discussion - Jim Schaad

Jim used slides for his two presentations.  Jim stated that the 2 July 98
Signing Certificate Attribute Specification (SIGATTR) I-D has been submitted
to the S/MIME WG mail list.  Jim stated that he would incorporate the
comment regarding replacing the IssuerAndSerialNumber field with
IssuerSerial so that Attribute Certificates can be identified.

There was some debate regarding whether the CertID certHash value should be
changed so that it is optional.

Jim asked if the attendees believe that the SIGATTR text should be
incorporated into CMS as a "MAY implement" option.

Paul agreed that the Signing Certificate Attribute should be included as a
"MAY implement" option in CMS.   

Dave Solo stated that he would like an enhancement to be made to the Signing
Certificate Attribute syntax to allow the identification of the complete
cert path of the signer (not just signer's cert).  This enhancement is
required so that the recipient can determine the context of the signer's
signature by examining the cert path of the signer's cert.  This issue
requires further debate on the list.

It was agreed that the SIGATTR text would not be incorporated into CMS until
all issues are resolved.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CERTDIST Draft Discussion - Jim Schaad

Jim stated that the 6 July 98 Certificate Distribution (CERTDIST) I-D has
been submitted to the S/MIME WG mail list.  Jim stated that the open issues
identified include:

1) Lack of content within the published message.  He considers this one
closed and that there will not be a content.  

2) Ability of CA and RA to publishing information on behalf of the user.
Through discussion with others, he has determined that the best solution
requires an extension in the RA's cert.  Issue: Is this overly broad for CAs
to issue?  Jim's current position is that only users can create these messages. 

Issue:  Is the fact that any parent CA could issue this and the fact that a
new Extension is required a problem.  Jim's current position is that the
risks out-weigh the benefits and that only users can create these messages.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

DOMSEC Draft Discussion - Bill Ottaway

Bill stated that the 15 July 98 Domain Security Services using S/MIME
(DOMSEC) I-D has been submitted to the S/MIME WG mail list.  When asked how
many people had read the DOMSEC I-D, many in the room raised their hands.
Bill presented the briefing slides stored on ftp://ftp.ietf.org/ietf/smime/.
These slides presented the basic points made in the DOMSEC I-D.  There were
no significant issues raised.  The question was asked from the floor (by
Paul Hoffman) as to the future plans for the document.  Bill said he was
happy to allow the working group to make that decision.  Paul said that the
DOMSEC I-D contained protocol, so it could not be progressed as an
informational document.  Chris Bonatti suggested that the protocol could be
moved into CMS, allowing the document to become informational.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Revocation Info in CMS - Paul Hoffman

Paul proposed that the message originator should be able to include non-CRL
revocation status information in the CMS heading "in case the recipient of
the message cannot (or does not want to) get the status information when
validating the signature, such as if the recipient is not online and no
usable CRLs were included in the SignedData."  For example, an OCSP response
could be included in the CMS heading.  This could be done via a new
attribute or by enhancing the CMS CRL list syntax.  This proposal requires
further debate on the list. 


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Wrap Up - Russ Housley

Russ asked for a straw poll of the attendees regarding which options the WG
should continue to pursue regarding the "mandatory-to-implement" KM issue.
The results are as follows:

1) Pursue S-S D-H option: about 20 hands raised

2) Pursue E-S D-H option: about 50 hands raised

3) Pursue self-signed E-S- D-H option: 0 hands raised

Based on this straw poll, options 1 and 2 will be pursued in parallel.  Russ
will investigate whether there are any patent issues with the E-S D-H
option.    Russ asked Tim Dierks to post further info regarding the Certicom
license offer.

======================================================
John Pawling                         [e-mail]
J.G. Van Dyke & Associates, Inc.     www.jgvandyke.com       
======================================================





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA02768 for ietf-smime-bks; Mon, 28 Sep 1998 06:03:32 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA02753 for <[e-mail]>; Mon, 28 Sep 1998 06:01:55 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id JAA16181; Mon, 28 Sep 1998 09:12:02 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id JAA00371; Mon, 28 Sep 1998 09:10:31 -0400
Date: Mon, 28 Sep 1998 09:10:31 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Denis Pinkas <[e-mail]>, Dr Stephen Henson <[e-mail]>
From: [e-mail] (John Pawling)
Subject: Re: 8/26/98 S/MIME WG Minutes
Cc: "[e-mail]" <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Denis,

Thank you very much for your feedback.  Russ asked that I submit the minutes
to "[e-mail]".  In the "official" minutes, I plan to change the
sentence "The attendees agreed that wording was sufficient." to "Denis said
that he would send a message to the S/MIME WG mail list regarding this topic
as a stimulus for further debate."

- John Pawling




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA00672 for ietf-smime-bks; Mon, 28 Sep 1998 03:09:19 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA00665 for <[e-mail]>; Mon, 28 Sep 1998 03:09:12 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id MAA24286; Mon, 28 Sep 1998 12:16:42 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id MAA10452; Mon, 28 Sep 1998 12:16:52 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Mon, 28 Sep 1998 12:17:06 -0700
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Dr Stephen Henson <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: 8/26/98 S/MIME WG Minutes
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Dr Stephen Henson has sent a few comments:

> A few comments.
>
> John Pawling wrote:
> >
> >
> > Slide #3: Signature Algorithms:
> >
> > DSA-with-SHA1 is mandatory to implement.  The attendees decided that the CMS
> > I-D will state that the parameters must be absent (not ASN.1 NULL).  This is
> > required for consistency with PKIX Part I.
> >
>
> I presume it is implied that a NULL parameter should be tolerated. I
> know of some implementations that generate NULL.
>
> >
> > Slide #8: Content Encryption Algorithms 2: The group decided that CMS will
> > document RC2 in CBC mode as a "should" to implement (rather than "may").
> > The RC2-CBC OID will be used.
> >
>
> Will this include the number of bits that may/should be supported as
> well?
>
> >
> > 1) Denis Pinkas asked if there was a way to verify the "correctness" of a
> > CMS message.  Denis considers signature generation time to be a critical
> > factor in determining whether or not that signature is valid.  If the
> > signing key is revoked, then the signing time would indicate if the message
> > signed before or after the revocation date.  John Pawling pointed out that
> > the MSG I-D already states that the signingTime attribute should always be
> > included in signed messages.  The attendees agreed that wording was sufficient.
> >
>
> IMHO this may need an additional comment.

Well, I don't think that "the attendees agreed that wording was sufficient" is the
right wording since I said during the last session in Chicago, that I would
reformulate a message sent on July 15, about :

1) the signature generation time,
2) the identification of the certificate.

The first item is precisely the topic raised by Stephan.

In the original message I was going straight to text replacement proposals with
insufficient explanations. Hereafter more explanations are provided, but, as
advertised, the text will be much longer. :-(

On page 10, the text says “ The input to the signature validation process includes
the result of the message digest calculation process and the signer’s public key”.

There is no information given here on the process by which the signer's public key is
obtained. If a wrong public key or a revoked key is being used, then the end result
of the verification process will be erroneous.

CMS can be used with real time communications or with store and forward environments,
i.e. within or without a S/MIME context. With real time communications, the signer’s
public key is either known from the context or will be extracted from the CMS syntax.
With store and forward environments, it is always be extracted from the CMS syntax.
This is where the danger lies.

It seems natural to use the issuerAndSerialNumber from the SignerInfo. The danger of
using it directly, without any additional control, is mentioned partly (i.e. one half
of it) in the document draft-ietf-smime-sigattr-01.txt [SIGATTR]... but no reference
is made to this document in CMS.

The danger here is to substitute a certificate by another one that would contain the
same public key value, since the issuerAndSerialNumber from the SignerInfo is NOT
part of the signature process. That situation may arise at least in two occasions:
the user has multiple certificates for the same public key from different CAs or a
malicious CA issues a certificate for a different entity while copying the public key
from another certificate. In the first case, a certificate that is different from the
certificate intended to be used by the signer is presented to the verifier, while in
the second case some "bad" CAs, i.e. omitting to perform POP -Proof of Possession of
the private key, cannot be detected. Full details are in [SIGATTR].

Substitutions can be detected by signing a Certificate Identifier.

However this is still insufficient to address the issue. The second part of it has to
do with key compromise. If a key is compromised, then the corresponding certificate
will be revoked. It is important to know if the certificate was revoked or not AT THE
TIME OF THE SIGNATURE. If it is not possible to know the time of the signature, then
unpredictable results may occurs in case of key compromise.

Although  John [Pawling] pointed out that the MSG I-D already states that the
signingTime attribute should always be included in signed messages, CMS can be used
in wider environments and thus people looking at CMS will not necessarily look at the
MSG I-D.

In addition, there are two unsolved problems with this approach:

1) the signingTime attribute alone does NOT solve the issue,
2) the current text of CMS is misleading on this issue. The current text of section
11.3 on page 29 says:

" No requirement is imposed concerning the correctness of the signing time, and
acceptance of a purported signing time is a matter of a recipient's discretion.  It
is expected, however, that some signers, such as time-stamp servers, will be trusted
implicitly."

The signingTime attribute only reflects the time the signer wanted to be included.
The signer may well pre-date that value, ... but more important, if the key of the
signer is compromised then an attacker may also pre-date that value. In such a
situation it cannot be made a difference between a past "honest" signature from the
right signer and a pre-dated "fake" signature from an attacker. This difference is
not important when CMS is used in real time contexts since the latest CRL or
equivalent will be used. However, if CMS is used in non repudiation contexts, then it
is important to be able to settle the dispute. The use of a Time Stamping Server can
then allow to make the difference between "good" and "fake" signatures.

Since CMS will be used in S/MIME environments but also in non-S/MIME environments as
a successor of PKS#7, we have two options either correct the text in the section 5.6
and 11.3 (on page 29) or provide more awareness in the "Security consideration
section" on page 40.

If the first option is chosen, then here is a full text replacement for that section:

" 5.6  Message Signature Validation Process

The input to the signature validation process includes the result of the message
digest calculation process and the signer's public key. It is fairly important to
pick up the right signer's public key, valid at the time the signature was made.

The signer’s public key can be known in advance from the context. In such a case it
may be used directly. When this is not the case, it has to be obtained from the
information present in the CMS message. If the issuerAndSerialNumber from the
SignerInfo is used, then a substitution of certificates containing the same public
key value is possible. If such a substitution is a concern then the threat can be
addressed by making the certificate identifier part of the signature as described in
the Signing Certificate Attribute Specification [SIGATTR]. In such a case the right
public key is contained in the certificate pointed by the signed certificate
identifier.

In order to make sure that this identified certificate is valid, e.g.using CRLs and
ARLs, it is important to know the status of the certificate at the time the signature
was performed.

If no time information is present in the CMS structure, then the assumption should be
that the message has just be signed. In that case the revocation information valid at
the time the verification is performed will be used.

If only the signingTime attribute is present, then no direct assumption can be made
on the time of the signature. If the certificate is not presently revoked and still
valid, then the time included in the signingTime attribute can be taken as the one
placed by the genuine signer and the certificate can be accepted. If the certificate
is presently revoked and/or no more valid, the verifier is at a risk to use
inadequate revocation information unless additional assurance may be obtained about
the time of the signature (see next).

If a counter signature from a trusted time Stamping Authority is used in addition to
the signingTime attribute and if these two time values are "close" enough (e.g. a few
hours) then the assumption should be that the signing time is the time mentioned in
the signingTime attribute. The revocation information that was valid at that signing
time should then be used.

The details of the signature validation depend on the signature algorithm employed.

The recipient may not rely on any message digest values computed by the originator.
If the signedData signerInfo includes signedAttributes, then the content message
digest must be calculated as described in section 5.4.  For the signature to be
valid, the message digest value calculated by the recipient must be the same as the
value of the messageDigest attribute included in the signedAttributes of the
signedData signerInfo."


In order to address the text from section 11.3 on page 29, here is a text
replacement.

" The signing time is only the purported signing time as indicated by the signer. No
further assurance can be given upon the accuracy of that time unless additional
assurance can be obtained through other means, e.g. a counter-signature from a Time
Stamping Server. In particular, it should be noticed that in case of key compromise,
the message can be signed by an attacker that may use a pre-dated time, i.e. a time
in the past when the certificate was not revoked. In such a case, unpredictable
results may occur."

The changes I have provided are rather conservative from the current structure. The
Signing Certificate Attribute Specification [SIGATTR] addresses two topics. One has
to do, as the title indicates it, with Attribute Certificates while the other has to
do with the certificate identifier from the signer. It would/might be better to move
the section relative to the certificate identifier from SIGATTR into CMS since this
is just another VERY "useful attribute" from the section 11.


> For example should the valdity (i.e. expiry) of the signing certificate
> chain use the current time or the signingTime?
>
> The signingTime attribute cannot be trusted in many cases.
>
> If a certificate is revoked due to key compromise an attacker could
> generate a message with a signingTime before it was revoked.
>
> The corollary to this is that if a certificate has been revoked then the
> posession of a signed message with a signingTime before the revokation
> time is not sufficient for nonrepudiation purposes. Some corroboration
> as to the signing time is required: such as a trusted timestamp
> countersignature.

I think that the new text proposal provided hereabove may address your perfectly
valid concern.

> > 3) Doug Maughn asked about the processing requirements for generating a
> > countersignature.  It was proposed on the list that the generator of a
> > countersignature must validate the original signature before generating the
> > countersignature.  Russ has included that proposal in the CMS draft that he
> > has not yet published.  He stated that "validate" means verify the signature
> > value of the CMS signedData, not necessarily validate the signer's cert path.
> >
>
> Does "verify the signature value of the CMS signedData" imply that just
> the digital signature of the signedData is checked or the messageDigest
> value as well, implying that the original content must be checked?
>
> IMHO checking signedData is tolerable but the original content
> verification has very serious implications, as I've mentioned before.
>
> Even so this affects some existing implementations: for example the
> Verisign AuthentiCode timestamper just takes the signedData signature
> and produces a trusted timestamp countersignature from that.

Denis

FYI, follows the original text from July 15.

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

Without waiting for a last call for CMS-06, here are my comments:

On page 10, the text says “ The input to the signature validation
process includes the result of the message digest calculation process
and the signer’s public key”. This is not sufficient in order to give
the same and relaible result between two different implementations. The
knowledge of the certificate of the signer as well as the time of the
signature are both important. If there is an ambiguity on one or the
other component then the end-result can be different.

1) About the CertUid of the signer

Unless the unambiguous identifier of the certificate of the signer is
part of the signed attributes, attacks are possible. This is a weakness
of the original PKS-7 document that should be corrected.

This has already be advertised on the PKIX list and explained during the
last meeting in LA. This relates to the POP (Proof of Private key
possession) issue. In other words, using the certificate identifier from
the signer as an additional signed attribute is the only way to make
sure, and at the time the verification is performed, that the user
really has possession of the signing private key, whether or not the CA
has done POP correctly. This protects again a malicious CA that would
"forget" to make POP.

This discussion also relates about the way to uniquely identify a
certificate. From previous E-mail exchanges it has been demonstrated
that in some cases the hash of the issuer public key was a way to
discriminate between synonymous issuer names. Thus the syntax of the
certificate identifier should be extended to optionally support a hash
of the issuer key.

2) About the signature time

Unless the time is securely known (using a time stamp over the CMS
message), the time should be considered to be the time at which the
signer makes the verification. This means that different results may be
obtained since the signer’s certificate may have been revoked since the
signature was produced (see the recent E-mails exchanges on the mailing
list).

In order to care for these cases, the following text is proposed as an
addition after the first sentence of the section 5.6:

 “ The signer’s public key can be known in advance from the context. In
that case it is directly used. When this is not the case, it has to be
obtained from the information present in the message. The CertUid
present in the signed certificate shall be used for that purpose.

In order to make sure that the identified certificate is valid, e.g.
using CRLs and ARLs, it is important to know the status of the
certificate at the time the signature was performed. When that time
cannot be reliably known, then, by default, the current time shall be
used. It should be noticed that this can lead to different results
depending upon the time the validation is performed. When that time is
reliably known, e.g. using a time stamp over the CMS message, then that
time shall be used. It should be noticed that leads to the same result
whatever the time the validation is performed.”

The section 11 should be extended to add the "CertUid" as a "usefull"
attribute.

At the last meeting in LA, I explained during the S/MIME session why it
is important to allow for the presence of a CertUid as a signed
attribute. Refer to the slides that I presented. This section should be
expanded to allow that attribute to be included here, otherwise there
would be serious security problems.

Proposed text:

11.X  Certificate Unique Identifier

   The Certificate-Unique-Identifier attribute type specifies
   unambiguously the certificate to be used for verifying the
   signature, when it is not known otherwise from the context.

   A Certificate-Unique-Identifier attribute must have a single
   attribute value.

   The following object identifier identifies the
   Certificate-Unique-Identifier attribute:

      id-certUid OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          XXXX }

   Certificate-Unique-Identifier attribute values have ASN.1 type
   CertUid:

      CertUid ::= CertId

      CertId ::= SEQUENCE {
          issuerAndSerialNumber    IssuerAndSerialNumber,
          hashIssuerPublicKey      HashIssuerPublicKey  OPTIONAL}

   The IssuerAndSerialNumber type identifies a certificate, and
   thereby an entity and a public key, by the name of the certificate
   issuer and an issuer-specific certificate serial number.

   The hashIssuerPublicKey allows to discriminate between two CAs
   that would have the same issuer name. Should that situation happen,
   then the two CAs would have different public keys. The hash of the
   public keys would thus be different.

      HashIssuerPublicKey ::= SEQUENCE {
            hashOid                 ObjectIdentifier,
            hashedIssuerPublicKey   OCTET STRING}


On page 5, there is a sentence stating: “The signer’s certificate may be
included in the SignedData certificates field”. It is not clear why the
whole certificate should be included. The CertUid (or CertID) would be
sufficient. If the full certificate is needed it does not need to be
part of the signed attributes (note that it is not part of the list of
“useful attributes” described in the section 11).

[Text deleted]

Denis


> Steve.
> --
> Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
> For info see homepage at http://www.drh-consultancy.demon.co.uk/
> Email: [e-mail]
> PGP key: via homepage.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26258 for ietf-smime-bks; Fri, 25 Sep 1998 17:28:43 -0700 (PDT)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26254 for <[e-mail]>; Fri, 25 Sep 1998 17:28:41 -0700 (PDT)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.03 #1) id 0zMiKX-0001oZ-00 for [e-mail]; Sat, 26 Sep 1998 00:35:21 +0000
Message-ID: <[e-mail]>
Date: Sat, 26 Sep 1998 01:33:11 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: 8/26/98 S/MIME WG Minutes
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I may have misinterpreted things, appologies. I wasn't objecting to the
minutes as such but making comments about the points raised. I couldn't
comment on the minutes: I wasn't there :-)

I'll just expand a little on my comment about tolerating NULL with DSA.
I've now had time to check Netscape Messenger in 4.06. It uses NULL
everywhere including SMIMECapabilities when signing using DSA with SHA1.
This isn't intended as a criticism of the Netscape implementation: it
probably pre-dates the recommendation.

I'll leave mentioning the rest until the other points are raised in due
course.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25559 for ietf-smime-bks; Fri, 25 Sep 1998 14:36:25 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25554 for <[e-mail]>; Fri, 25 Sep 1998 14:36:24 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id RAA11128; Fri, 25 Sep 1998 17:46:43 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id RAA05588; Fri, 25 Sep 1998 17:45:14 -0400
Date: Fri, 25 Sep 1998 17:45:14 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Dr Stephen Henson <[e-mail]>, "[e-mail]" <[e-mail]>
From: [e-mail] (John Pawling)
Subject: Re: 8/26/98 S/MIME WG Minutes
Sender: [e-mail]
Precedence: bulk

Steve,

Thank you very much for your feedback.  My replies are in-line:


At 09:24 PM 9/25/98 +0100, Dr Stephen Henson wrote:
>A few comments.
>
>John Pawling wrote:
>> 
>> 
>> Slide #3: Signature Algorithms:
>> 
>> DSA-with-SHA1 is mandatory to implement.  The attendees decided that the CMS
>> I-D will state that the parameters must be absent (not ASN.1 NULL).  This is
>> required for consistency with PKIX Part I.
>> 
>
>I presume it is implied that a NULL parameter should be tolerated. I
>know of some implementations that generate NULL.


[JSP: In the case of id-dsa-with-sha1, there was no specific discussion
during the meeting of accepting a NULL parameter.  The proposed text for
CMS, Sec 12 regarding id-dsa-with-sha1 includes the following:
   
"12.2.1  DSA

The DSA signature algorithm is defined in FIPS Pub 186 [FIPS 186]. The
algorithm identifier for DSA is:

    id-dsa-with-sha1 OBJECT IDENTIFIER ::=  { iso(1) member-body(2)
        us(840) x9-57 (10040) x9cm(4) 3 }

The AlgorithmIdentifier parameter field must not be present."

In my opinion, if the receiving software is supposed to be tolerant of a
NULL parameter in this case, then that fact should be specificaly stated in
CMS, Sec 12.2.1.  Personally, I believe that a NULL value should be
tolerated, especially since the X9.57 document that defines this OID is
ambiguous regarding this point.

In summary, I believe that you have a valid comment regarding CMS Section
12, but not against the minutes since this issue was not discussed regarding
this specific OID.]



>> 
>> Slide #8: Content Encryption Algorithms 2: The group decided that CMS will
>> document RC2 in CBC mode as a "should" to implement (rather than "may").
>> The RC2-CBC OID will be used.
>> 
>
>Will this include the number of bits that may/should be supported as
>well?


[JSP: There was no specific discussion of this issue during the meeting.
The proposed text for CMS, Sec 12 regarding RCS CBC includes the following:
   
"12.5.3  RC2 CBC

The RC2 algorithm is described in RFC 2268. The algorithm identifier for
RC2 in CBC mode is:

    RC2-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) encryptionAlgorithm(3) 2}

For the effective-key-bits (key size) greater than 32 and less than
256, the RC2-CBC algorithm parameters are encoded as:

    RC2-CBC parameter ::=  SEQUENCE {
        rc2ParameterVersion  INTEGER,
        iv                   OCTET STRING (8)}

For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
values are 160, 120, 58 respectively. It is very important to note that
these values are not simply the RC2 keylength. Also note that the value 160
must be encoded as two octets (00 A0), because encoding as one octet (A0)
is a negative number in ASN.1."

Does this answer your question???]




>> 
>> 1) Denis Pinkas asked if there was a way to verify the "correctness" of a
>> CMS message.  Dennis considers signature generation time to be a critical
>> factor in determining whether or not that signature is valid.  If the
>> signing key is revoked, then the signing time would indicate if the message
>> signed before or after the revocation date.  John Pawling pointed out that
>> the MSG I-D already states that the signingTime attribute should always be
>> included in signed messages.  The attendees agreed that wording was
sufficient.
>> 
>
>IMHO this may need an additional comment.
>
>For example should the valdity (i.e. expiry) of the signing certificate
>chain use the current time or the signingTime? 
>
>The signingTime attribute cannot be trusted in many cases.
>
>If a certificate is revoked due to key compromise an attacker could
>generate a message with a signingTime before it was revoked.
>
>The corollary to this is that if a certificate has been revoked then the
>posession of a signed message with a signingTime before the revokation
>time is not sufficient for nonrepudiation purposes. Some corroboration
>as to the signing time is required: such as a trusted timestamp
>countersignature. 


[JSP: Were these statements made during the meeting?  I confess that I did
not hear every word said during the meeting and that the tape player that I
used to record the meeting was not sensitive enough to pick up every word
said at the meeting.  The minutes of the meeting are supposed to cover the
events of the meeting.  If these statements were made during the meeting,
then I do not object to their inclusion in the minutes.  The minutes are not
intended to cover every possible point (valid though they may be) regarding
a topic, so if these statements were not made during the meeting, then I
don't believe that they should be included in the minutes.]  



>> 
>> 3) Doug Maughn asked about the processing requirements for generating a
>> countersignature.  It was proposed on the list that the generator of a
>> countersignature must validate the original signature before generating the
>> countersignature.  Russ has included that proposal in the CMS draft that he
>> has not yet published.  He stated that "validate" means verify the signature
>> value of the CMS signedData, not necessarily validate the signer's cert path.
>> 
>
>Does "verify the signature value of the CMS signedData" imply that just
>the digital signature of the signedData is checked or the messageDigest
>value as well, implying that the original content must be checked?


[JSP: This issue was not specifically discussed during the meeting.  I
believe that you have a valid comment regarding CMS, but not against the
minutes.]



>
>IMHO checking signedData is tolerable but the original content
>verification has very serious implications, as I've mentioned before.
>
>Even so this affects some existing implementations: for example the
>Verisign AuthentiCode timestamper just takes the signedData signature
>and produces a trusted timestamp countersignature from that.

[JSP: Recommend that you continue to pursue this point on the list.]


>
>Steve.
>-- 
>Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
>For info see homepage at http://www.drh-consultancy.demon.co.uk/
>Email: [e-mail]
>PGP key: via homepage.
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25448 for ietf-smime-bks; Fri, 25 Sep 1998 14:21:20 -0700 (PDT)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25438; Fri, 25 Sep 1998 14:21:15 -0700 (PDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]>; Fri, 25 Sep 1998 14:27:06 PDT
Date: Fri, 25 Sep 1998 14:22:57 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-reply-to: "Your message dated Fri, 25 Sep 1998 15:10:52 -0500" <[e-mail]>
To: "William H. Geiger III" <[e-mail]>
Cc: Ned Freed <[e-mail]>, Graham Klyne <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25303 for ietf-smime-bks; Fri, 25 Sep 1998 14:06:36 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25299; Fri, 25 Sep 1998 14:06:34 -0700 (PDT)
Received: from whgiii (dugong35.pcola.gulf.net [205.160.71.98]) by domains.invweb.net (8.9.1/8.9.1) with SMTP id RAA22106; Fri, 25 Sep 1998 17:12:36 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Fri, 25 Sep 1998 16:00:40 -0500
To: "Blake Ramsdell" <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: "Steve Hole" <[e-mail]>, "Ned Freed" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

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

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

>> -----Original Message-----
>> From: William H. Geiger III [mailto:[e-mail]]
>> Sent: Friday, September 25, 1998 1:22 PM
>> To: Steve Hole
>> Cc: Ned Freed; [e-mail]; [e-mail]
>> Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
>> 
>> In <[e-mail]>, on 09/18/98 
>>    at 10:55 AM, Steve Hole <[e-mail]> 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!

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNgwJTY9Co1n+aLhhAQE96gQAlGhKml9VG7pPUnY+7lDTudU8RN+KFcVF
Ds/LHrL0LEQYQj/y6XZ+ai4Vq4OjLCEQnJTG41qJqUnMhNcNTDR3JbUXyEY4bCta
a4Uw18dOavsbT525YPc+9emOUbl62FAAbjsdnDSLN8ACBwhyD8IuPjDdTloAUTSk
avXbyVsbkX4=
=fkoP
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25122 for ietf-smime-bks; Fri, 25 Sep 1998 13:41:15 -0700 (PDT)
Received: from cane.deming.com (cane.deming.com [208.236.41.9] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA25112; Fri, 25 Sep 1998 13:41:07 -0700 (PDT)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2); Fri, 25 Sep 98 13:47:41 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.1960.3) id <TRZ1SYRN>; Fri, 25 Sep 1998 13:47:40 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'William H. Geiger III'" <[e-mail]>, "Steve Hole" <[e-mail]>
cc: "Ned Freed" <[e-mail]>, <[e-mail]>, <[e-mail]>
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
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
X-WSS-ID: 1A12DEE79923-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: William H. Geiger III [mailto:[e-mail]]
> Sent: Friday, September 25, 1998 1:22 PM
> To: Steve Hole
> Cc: Ned Freed; [e-mail]; [e-mail]
> Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
> 
> In <[e-mail]>, on 09/18/98 
>    at 10:55 AM, Steve Hole <[e-mail]> 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 [phone] x103  Fax [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA24924 for ietf-smime-bks; Fri, 25 Sep 1998 13:20:20 -0700 (PDT)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24920 for <[e-mail]>; Fri, 25 Sep 1998 13:20:19 -0700 (PDT)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.03 #1) id 0zMeS9-00051V-00 for [e-mail]; Fri, 25 Sep 1998 20:26:58 +0000
Message-ID: <[e-mail]>
Date: Fri, 25 Sep 1998 21:24:10 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: 8/26/98 S/MIME WG Minutes
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

A few comments.

John Pawling wrote:
> 
> 
> Slide #3: Signature Algorithms:
> 
> DSA-with-SHA1 is mandatory to implement.  The attendees decided that the CMS
> I-D will state that the parameters must be absent (not ASN.1 NULL).  This is
> required for consistency with PKIX Part I.
> 

I presume it is implied that a NULL parameter should be tolerated. I
know of some implementations that generate NULL.

> 
> Slide #8: Content Encryption Algorithms 2: The group decided that CMS will
> document RC2 in CBC mode as a "should" to implement (rather than "may").
> The RC2-CBC OID will be used.
> 

Will this include the number of bits that may/should be supported as
well?

> 
> 1) Denis Pinkas asked if there was a way to verify the "correctness" of a
> CMS message.  Dennis considers signature generation time to be a critical
> factor in determining whether or not that signature is valid.  If the
> signing key is revoked, then the signing time would indicate if the message
> signed before or after the revocation date.  John Pawling pointed out that
> the MSG I-D already states that the signingTime attribute should always be
> included in signed messages.  The attendees agreed that wording was sufficient.
> 

IMHO this may need an additional comment.

For example should the valdity (i.e. expiry) of the signing certificate
chain use the current time or the signingTime? 

The signingTime attribute cannot be trusted in many cases.

If a certificate is revoked due to key compromise an attacker could
generate a message with a signingTime before it was revoked.

The corollary to this is that if a certificate has been revoked then the
posession of a signed message with a signingTime before the revokation
time is not sufficient for nonrepudiation purposes. Some corroboration
as to the signing time is required: such as a trusted timestamp
countersignature. 

> 
> 3) Doug Maughn asked about the processing requirements for generating a
> countersignature.  It was proposed on the list that the generator of a
> countersignature must validate the original signature before generating the
> countersignature.  Russ has included that proposal in the CMS draft that he
> has not yet published.  He stated that "validate" means verify the signature
> value of the CMS signedData, not necessarily validate the signer's cert path.
> 

Does "verify the signature value of the CMS signedData" imply that just
the digital signature of the signedData is checked or the messageDigest
value as well, implying that the original content must be checked?

IMHO checking signedData is tolerable but the original content
verification has very serious implications, as I've mentioned before.

Even so this affects some existing implementations: for example the
Verisign AuthentiCode timestamper just takes the signedData signature
and produces a trusted timestamp countersignature from that.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA24867 for ietf-smime-bks; Fri, 25 Sep 1998 13:14:47 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24863; Fri, 25 Sep 1998 13:14:46 -0700 (PDT)
Received: from whgiii (dugong35.pcola.gulf.net [205.160.71.98]) by domains.invweb.net (8.9.1/8.9.1) with SMTP id QAA21333; Fri, 25 Sep 1998 16:20:53 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Fri, 25 Sep 1998 15:21:52 -0500
To: Steve Hole <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

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

In <[e-mail]>, on 09/18/98 
   at 10:55 AM, Steve Hole <[e-mail]> 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.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNgv9Lo9Co1n+aLhhAQEAHAP9FFdmZZD3I8q8R3UgA1Kurzi/GrTOKVkV
jr6t/lSwokNc08qGjusFeu7TwNQHA/dJ/kc60F0whpO0VtLvDc6dW1GopWwJMFSh
p3JhRcltgBdQ/xm/RUbpvdTsaxd5V0vWYV80QzaYqR3EeUz4jVuSJ5ddei2iVvIh
mrrCPdTaVU8=
=ebIz
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA24778 for ietf-smime-bks; Fri, 25 Sep 1998 13:00:59 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24774; Fri, 25 Sep 1998 13:00:56 -0700 (PDT)
Received: from whgiii (dugong35.pcola.gulf.net [205.160.71.98]) by domains.invweb.net (8.9.1/8.9.1) with SMTP id QAA21078; Fri, 25 Sep 1998 16:06:54 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Fri, 25 Sep 1998 15:10:52 -0500
To: Ned Freed <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: Graham Klyne <[e-mail]>, Ned Freed <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

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

In <[e-mail]>, on 09/24/98 
   at 02:18 AM, Ned Freed <[e-mail]> 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.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNgv56I9Co1n+aLhhAQFtWgP5AYc4VB8+BmNGIDFmrPh8fJ46VOl0a5iU
VZAi1K054hzQvSKO9CxpZUg6QmNazTG0f+GsUo7NriwnfdSd4OjWNgKDsgK/g0Tg
RHsUz6+YexthqXSgQqA1UEv/fcuXSSQY3nhUP3/lmDvy0mFBXB38Bxx2JXPm7Y/V
88XJgeIIrNg=
=qx1V
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25698 for ietf-smime-bks; Thu, 24 Sep 1998 14:04:43 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25694 for <[e-mail]>; Thu, 24 Sep 1998 14:04:42 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id OAA15072 for <[e-mail]>; Thu, 24 Sep 1998 14:10:46 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Thu, 24 Sep 1998 15:38:20 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Minutes
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

I have seen no discussion of the minutes posted by John Pawling.  I plan to
submit tomorrow, so if you have comments, please post them now.

Russ



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA17332 for ietf-smime-bks; Thu, 24 Sep 1998 01:00:38 -0700 (PDT)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA17295; Thu, 24 Sep 1998 00:57:27 -0700 (PDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]>; Thu, 24 Sep 1998 01:03:31 PDT
Date: Thu, 24 Sep 1998 00:18:57 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-reply-to: "Your message dated Wed, 23 Sep 1998 10:18:05 +0100" <[e-mail]>
To: Graham Klyne <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18424 for ietf-smime-bks; Wed, 23 Sep 1998 02:12:27 -0700 (PDT)
Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA18414 for <[e-mail]>; Wed, 23 Sep 1998 02:12:26 -0700 (PDT)
Received: (qmail 7809 invoked from network); 23 Sep 1998 09:18:52 -0000
Received: from userp453.uk.uudial.com (HELO GK) (193.149.92.198) by smtp.dial.pipex.com with SMTP; 23 Sep 1998 09:18:52 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 23 Sep 1998 10:18:05 +0100
To: Ned Freed <[e-mail]>
From: Graham Klyne <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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
([e-mail])



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28381 for ietf-smime-bks; Tue, 22 Sep 1998 09:32:25 -0700 (PDT)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28367; Tue, 22 Sep 1998 09:30:29 -0700 (PDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]>; Tue, 22 Sep 1998 09:36:43 PDT
Date: Tue, 22 Sep 1998 09:32:09 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-reply-to: "Your message dated Tue, 22 Sep 1998 11:13:53 +0100" <[e-mail]>
To: Graham Klyne <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA23857 for ietf-smime-bks; Tue, 22 Sep 1998 03:08:28 -0700 (PDT)
Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA23853 for <[e-mail]>; Tue, 22 Sep 1998 03:08:26 -0700 (PDT)
Received: (qmail 22537 invoked from network); 22 Sep 1998 10:14:38 -0000
Received: from userl982.uk.uudial.com (HELO GK) (193.149.77.33) by smtp.dial.pipex.com with SMTP; 22 Sep 1998 10:14:38 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 22 Sep 1998 11:13:53 +0100
To: Ned Freed <[e-mail]>
From: Graham Klyne <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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
([e-mail])



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01392 for ietf-smime-bks; Mon, 21 Sep 1998 13:58:00 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01388 for <[e-mail]>; Mon, 21 Sep 1998 13:57:59 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id OAA08769; Mon, 21 Sep 1998 14:03:40 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Mon, 21 Sep 1998 16:12:53 -0400
To: "Linn, John" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Proposed CMS security considerations re PKCS #1
Cc: [e-mail]
In-Reply-To: <[e-mail] mics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

John:

Your suggested changes are incorporated....

Russ


At 10:30 AM 9/18/98 -0400, Linn, John wrote:
>Russ:
>
>Thanks for incorporating the material.  This looks generally good; I'd like
>to suggest two clarifications and fix one typo, embedded below:
>
>> ----------
>> From: 	Russ Housley[SMTP:[e-mail]]
>> Sent: 	Thursday, September 17, 1998 1:42 PM
>> To: 	[e-mail]
>> Cc: 	[e-mail]
>> Subject: 	Re: Proposed CMS security considerations re PKCS #1
>> 
>> John:
>> 
>> Thanks for the contribution.  I made a few chanes to make the words flow
>> with
>> the rest of the Security Considerations section.  PLease let me know if I
>> messed anything up in the process.
>> 
>> Russ
>> 
>> 
>> [inserted in CMS Security considerations]
>> 
>> Users of CMS, particularly those employing CMS to support interactive
>> applications, should be aware that PKCS #1 [RFC 2313] is vulnerable to
>> adaptive
>> chosen ciphertext attacks when applied for encryption purposes.
>> Exploitation
>> of this identified vulnerability, revealing the result of a particular RSA
>> decryption, requires access to an oracle which will respond to a large
>> number
>> of ciphertexts (perhaps hundreds of thousands)
>> 
>Suggest replacing "(perhaps hundreds of thousands)" with "(based on
>currently available results, hundreds of thousands or more)".
>
>> , which are constructed
>> adaptively in response to previously-received replies providing
>> information on
>> the results 
>> 
>Consistent with the second paragraph, I suggest changing "the results" to
>"the successes or failures"; sorry for not already having framed this
>sentence in this fashion. 
>
>> of attempted decryption operations.  As a result, the attack
>> appears significantly less feasible to perpetrate for store-and-forward
>> S/MIME
>> environments than for directly interactive protocols.  Where CMS
>> constructs
>> are
>> applied as an intermediate encryption layer within an interactive
>> request-response communications environment, exploitation could be more
>> feasible.
>> 
>> An updated version of PKCS #1 has been published as an Internet-Draft, and
>> the
>> new document is targeted to become PKCS #1 Version 2.0 and to succeed RFC
>> 2313.  To resolve the adaptive chosen ciphertext vulnerability, the new
>> document specifies and recommends use of Optimal Asymmetric Encryption
>> Padding
>> (OAEP) when RSA encryption is applied to provide secrecy.  Designers of
>> protocols and systems employing CMS for interactive environments should
>> either
>> consider usage of OAEP, or should ensure that information which could
>> reveal
>> the success or failure of attempted PKCS #1 decryption operations
>> in not
>> 
>Typo: "in not" -> "is not".
>
>> provided.  Support for OAEP may be added to a future version of the CMS
>> specification once the PKCS#1 Version 2.0 is stable.
>> 
>--jl
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23384 for ietf-smime-bks; Fri, 18 Sep 1998 10:14:40 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23380 for <[e-mail]>; Fri, 18 Sep 1998 10:14:38 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id NAA07246 for <[e-mail]>; Fri, 18 Sep 1998 13:24:12 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id NAA23488; Fri, 18 Sep 1998 13:22:45 -0400
Date: Fri, 18 Sep 1998 13:22:45 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: 8/26/98 S/MIME WG Minutes
Sender: [e-mail]
Precedence: bulk

All,

This message includes the minutes of the IETF S/MIME Working Group (WG)
meeting held on 26 August 1998 in Chicago, IL.  These minutes have been
coordinated with the briefing presenters.  All briefing slides are stored
at: ftp://ftp.ietf.org/ietf/smime/.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Introductions - Russ Housley
 
Russ reviewed the agenda.  Nobody objected to the agenda.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

MSG Draft Discussion - Blake Ramsdell

Blake stated that the 6 Aug 98 S/MIME v3 Message Specification (MSG)
Internet Draft (I-D) includes the comments submitted to the S/MIME WG mail
list.  He  stated that the application/MIME text was deleted from MSG and
the X.509 references were changed to PKIX references.  When asked if there
were any other comments to the MSG I-D, the room was silent.  When asked how
many people had read the MSG I-D, not many in the room raised their hands.
Blake stated that the MSG I-D has been submitted for last call within the
S/MIME WG and that there are no other changes planned for the MSG I-D. 
 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CERT Draft Discussion - Blake Ramsdell

Blake stated that the 6 Aug 98 S/MIME v3 Certificate Handling (CERT) I-D
includes the comments submitted to the S/MIME WG mail list.  He stated that
the CERT I-D has been submitted for last call within the S/MIME WG.  When
asked how many people had read the CERT I-D, not many in the room raised
their hands.  Blake stated that the X.509 references were changed to PKIX
references.  There was a comment from an attendee that Section 3.2 "Required
Name Attributes" should be deleted because it is redundant to the PKIX X.509
Certificate and CRL Profile (PKIX Part I).  Nobody objected to this change.
There was a comment from an attendee who was concerned that certificates
included in S/MIME messages may divulge sensitive information.  The
consensus of the attendees was that this is a matter to be solved by the
policy of the local organization of the user who is releasing the S/MIME
message.  The group decided that no change is required in the S/MIME I-Ds
regarding this issue.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

ESS Draft Discussion - Paul Hoffman

Paul stated that the 5 Aug 98 Enhanced Security Services for SMIME (ESS) I-D
has been submitted for last call within the S/MIME WG.  When asked how many
people had read the ESS I-D, not many in the room raised their hands.  Paul
stated that the EntityIdentifier syntax needs to be added to the ESS I-D
ASN.1 module as noted on the S/MIME WG mail list.  He stated that the S/MIME
ASN.1 modules need to be compiled by various ASN.1 toolkits to determine if
there are any other discrepancies.  Van Dyke and Associates (VDA)
volunteered to compile the ESS and CMS I-D ASN.1 modules using the SNACC
ASN.1 compiler, but others were urged to check the ASN.1 with their own
compilers as well.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CMS Draft Discussion - Russ Housley

Russ presented briefing slides (see ftp://ftp.ietf.org/ietf/smime/)
regarding the open issues related to the June 98 Cryptographic Message
Syntax (CMS) I-D.  Russ stated that the ESS, CERT and MSG I-Ds are dependent
on the CMS I-D; therefore, those I-Ds will not complete WG Last Call until
the CMS I-D completes WG Last Call.  When CMS enters WG Last Call, then all
of the I-Ds will be final after the two-week last call period is complete.
In summary, the WG last call period will simultaneously close for the CMS,
ESS, CERT and MSG I-Ds. 


Slide #1: CMS Document Status:  All CMS sections are complete except for
Section 12 that will document the mandatory algorithms and some optional
algorithms.  The comments received on the mail list have been incorporated
into a CMS draft that has not yet been released to the WG.  A draft of
Section 12 was discussed on the mail list.  The most recent draft is
included in the 22 July message, subject: "CMS Section 12, take 3".  The
completion of Section 12 depends on the Diffie-Hellman (D-H) Key Agreement
Method I-D <draft-ietf-smime-x942-00.txt>.


Slide #2: Message Digest Algorithms: 

SHA-1 is mandatory to implement.  The AlgorithmIdentifier syntax includes an
optional parameters field.  There was some debate regarding whether the
parameters field should be absent or set to an ASN.1 NULL (05 00 hex) when
the SHA-1 OID is populated in the AlgorithmIdentifier syntax.  Eric Rescorla
and Blake pointed out that current implementations encode the field as an
ASN.1 NULL.  The attendees decided that the CMS I-D will state that the
parameters must be encoded as an ASN.1 NULL, but that CMS implementations
should be able to accept either an ASN.1 NULL or absent parameters.  This is
required for compatibility with S/MIME v2.     

MD5 is optional to implement.  The attendees decided that the CMS I-D will
state that the parameters must be encoded as an ASN.1 NULL when the MD5 OID
is populated in the AlgorithmIdentifier syntax.  This is required for
compatibility with S/MIME v2.     


Slide #3: Signature Algorithms:  

DSA-with-SHA1 is mandatory to implement.  The attendees decided that the CMS
I-D will state that the parameters must be absent (not ASN.1 NULL).  This is
required for consistency with PKIX Part I.

RSA-with-SHA1 and RSA-with-MD5 are optional to implement.  With both of
these combinations, the rsaEncryption OID must be used in the signedData
signerInfo signatureAlgorithm.  The digesting algorithm is indicated in the
signedData signerInfo digestAlgorithm.  The attendees decided that the CMS
I-D will state that the parameters must be encoded as an ASN.1 NULL when the
rsaEncryption OID is populated in the AlgorithmIdentifier syntax.  This is
required for compatibility with S/MIME v2.     


Slide #4: Key Management (KM) Algorithms: 

The group discussed which KM algorithms and key encryption algorithms should
be documented in CMS.  The attendees decided that the most important
algorithms to cover are the mandatory-to-implement algorithms.  The
attendees agreed that optional algorithms not already covered in CMS can be
documented in separate I-Ds. 

The proposed Section 12 text states that static D-H (as specified in the D-H
I-D) will be mandatory to implement.  CMS will document how static D-H can
be used to generate a key-encryption key (KEK) for use with Triple DES.  It
will also document how static D-H can be used to generate a KEK for use with
RC2. 

When obtaining the bits of the KEK, the minimal number of bits needed to
form the KEK must be used (a.k.a. key reduction).  There is an open issue
regarding how the minimal number of bits is obtained for RC2.  The group
decided that this issue will be debated on the list.

The group decided that CMS should not discuss the use of D-H to generate
keys for DES.  

The group decided that CMS should specify that at least 512 modulus should
be used.

An attendee asked about key recovery.  Russ stated that this issue has been
thoroughly discussed on the mail list and that discussion identified at
least three ways to implement key recovery without specifying a specific
strategy in CMS. 


Slide #5: Key Management (KM) Algorithms 2:  Mail List Key (MLK) encryption
is optional to implement.  CMS will discuss the use of Triple-DES and RC2 to
be used for MLK purposes.


Slide #6: Key Wrapping Algorithm:  CMS will document a single
mandatory-to-implement key wrapping strategy to be used with key agreement
and MLK (but not key transport).  Jim Schaad asked if an OID should be
defined to identify the wrapping algorithm.  Russ answered that the X9.42
D-H OID used in conjunction with CMS implies the wrapping algorithm.  John
Pawling pointed out that Sec 12.4, 3rd paragraph states: "Triple-DES may be
an exception here; the same identifier is used for both 2-key and 3-key
Triple DES.  This is probably easily handled by always wrapping three keys,
even if the first and third keys match."  John stated that these issues need
to be resolved to avoid interoperability problems. 

Slide #7: Content Encryption Algorithms:  Triple-DES in CBC mode is the
mandatory-to-implement algorithm.  The DES-EDE3-CBC OID will be used.   The
group decided that DES will not be documented in CMS. 


Slide #8: Content Encryption Algorithms 2: The group decided that CMS will
document RC2 in CBC mode as a "should" to implement (rather than "may").
The RC2-CBC OID will be used.

Slide #9: Message Authentication Code (MAC) Algorithms:  The group decided
by a clear majority that HMAC-with-SHA1 will be the mandatory-to-implement
algorithm.  The wording in CMS will be: "If authenticatedData is
implemented, then HMAC-with-SHA1 must be implemented."  The group also
decided that DES MAC will not be included in CMS as an optional algorithm.

Slide #10: Way Forward:  When Section 12 is completed, then CMS will be
ready for last call.  Russ asked if there were any other issues.

1) Denis Pinkas asked if there was a way to verify the "correctness" of a
CMS message.  Dennis considers signature generation time to be a critical
factor in determining whether or not that signature is valid.  If the
signing key is revoked, then the signing time would indicate if the message
signed before or after the revocation date.  John Pawling pointed out that
the MSG I-D already states that the signingTime attribute should always be
included in signed messages.  The attendees agreed that wording was sufficient.

2) Denis also was concerned that the serial number in the signer's cert is
not covered by the signedData signerInfo signature, so a different cert
could be substituted for the signer's cert.  Russ stated that the SIGATTR
I-D addresses this issue.

3) Doug Maughn asked about the processing requirements for generating a
countersignature.  It was proposed on the list that the generator of a
countersignature must validate the original signature before generating the
countersignature.  Russ has included that proposal in the CMS draft that he
has not yet published.  He stated that "validate" means verify the signature
value of the CMS signedData, not necessarily validate the signer's cert path.

4) John Linn proposed that text should be added to the Security
Considerations section regarding the use of PKCS #1 v2.  The group agreed
that this was a good idea.  John Linn agreed to provide the text for the
Security Considerations section of CMS.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

X9.42 Draft Discussion - Russ Housley

The D-H Key Agreement Method I-D (a.k.a. D-H I-D) is required before CMS can
progress to WG Last Call.  After the D-H I-D was published to the list, Russ
asked if there were any patents that applied to the D-H variant documented
in the I-D.  Certicom announced on the list that they have applied for a
patent that covers the variant of the D-H algorithm specified in the D-H
I-D.  He proposed two alternatives: 1) CMS and D-H I-Ds could continue to
mandate the current D-H variant; or 2) WG could pursue a different D-H
variant as the mandatory-to-implement KM algorithm to avoid the delay
associated with working out the licensing agreement with Certicom.

Russ presented a slide describing another variant.  The variant currently
documented in D-H I-D is called Static-Static (S-S) D-H.  With S-S D-H, the
originator has a static key and the recipient has a static key both of which
are contained in certificates.  The alternative is called Ephemeral-Static
(E-S) D-H.  With E-S D-H, the recipient has a static key contained in a
certificate, but the originator generates an ephemeral key not contained
within a certificate.  Russ stated that the E-S D-H would need to be
documented and then distributed to determine if there are any patents or
pending patents that apply to the E-S D-H variant.  He stated that the E-S
D-H has some of the same properties as the Open PGP D-H strategy, but not
identical.  Paul Hoffman noted that there have been no patent statements
made regarding the Open PGP D-H strategy. 

Russ presented the following info:

          S-S D-H              |         E-S D-H
-------------------------------|--------------------------------
Pending patent                 | No patents (?)
1 exponentiation per recipient | 2 exponentiations per recipient
Data origin authentication     | No authentication
Shorter certificate            | Longer certificate (p,q,g) 
			       | (about 200 bytes longer)
Originator cert in message     | Originator cert not in message
Common p,q,g parameters        | Use recipient's p,q,g values

The question was asked if q is really required to be transmitted in the CMS
heading.  Russ stated that q should be included so that the existing X9.42
ASN.1 syntax for the p,q,g parameters can be used.  Also, the q value can be
used to validate the p and g values.    

Darren Harter pointed out that there is another option in which the
originator would produce a self-signed E-S D-H cert and include it in the
message.

Tim Dierks from Consensus Development Corporation/Certicom spoke regarding
Certicom's pending patent that they believe covers the X9.42 D-H variant.
Tim stated that Certicom is willing to issue a royalty-free license to
S/MIME and PKIX vendors to use the technology covered by their pending
patent. Tim stated that any applicant must divulge their own patents and
pending patents that would block the implementation of the mandatory
requirements of PKIX or CMS.  Tim stated that Certicom will require that the
applicant issue a royalty-free license to Certicom covering the applicant's
patented technology.   Tim stated that Certicom intends to gain revenue for
use of the technology in "non-S/MIME" cases.

Eric Rescorla pointed out that the S/MIME WG's acceptance of this option
would limit future vendor's options.  He also pointed out that CMS is used
in applications other than S/MIME, so the Certicom's offer does not benefit
all users of CMS.

Paul pointed out that there is not an official definition of "S/MIME", so
the limitation to issue licenses to "S/MIME" vendors is problematic.  Paul
also pointed out that there will probably be future versions of the S/MIME
specifications.  Paul reiterated Eric's statement that CMS is used in
applications other than S/MIME.

Jeff Schiller, the IETF Security Are Co-Director, expressed his desire to
avoid a situation in which licenses must be obtained to implement
mandatory-to-implement features.  He was concerned with the restrictions
placed by Certicom's proposal regarding how CMS is to be used.  Jeff stated
that he had difficulty with the "S/MIME" limitation included in Certicom's
offer because not all CMS implementers would be able to obtain the
royalty-free license.  Jeff stated that he liked the E-S D-H option better
than the S-S D-H option due to technical reasons in addition to the patent
issues.  Jeff stated that he has found that the two exponentiations required
to be calculated for each recipient in the E-S D-H option is acceptable as
far as performance is concerned.

John Pawling pointed out that some vendors are implementing CMS/ESS security
libraries that could be used by "S/MIME" or "non-S/MIME" applications, so
this further complicates the issue.  He pointed out that the E-S option
eliminates the need to validate the originator's KM cert, so a significant
time saving is achieved.  He recommended that the WG should pursue both the
E-S D-H and S-S D-H options in parallel.  Several attendees agreed with this
plan.

Dave Solo pointed out that some environments consist of an "S/MIME"
application on one end of a transaction and a "non-S/MIME" application on
the other end.  Dave also asked if there was an issue with using the E-S D-H
option with forming a pairwise key with yourself.  Russ stated that that
there will not be a problem with that operation.

Tim stated that he would obtain more info from Certicom.  Later in the
meeting after talking with Certicom via telephone, Tim stated that Certicom
agreed to provide royalty-free licenses for all uses of CMS, not just for
use in "S/MIME" applications.  Tim stated that the license would also cover
the use of S-S D-H in future versions of the CMS and PKIX specifications
(not just S/MIME v3). 


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

SIGATTR Draft Discussion - Jim Schaad

Jim used slides for his two presentations.  Jim stated that the 2 July 98
Signing Certificate Attribute Specification (SIGATTR) I-D has been submitted
to the S/MIME WG mail list.  Jim stated that he would incorporate the
comment regarding replacing the IssuerAndSerialNumber field with
IssuerSerial so that Attribute Certificates can be identified.

There was some debate regarding whether the CertID certHash value should be
changed so that it is optional.

Jim asked if the attendees believe that the SIGATTR text should be
incorporated into CMS as a "MAY implement" option.

Paul agreed that the Signing Certificate Attribute should be included as a
"MAY implement" option in CMS.   

Dave Solo stated that he would like an enhancement to be made to the Signing
Certificate Attribute syntax to allow the identification of the complete
cert path of the signer (not just signer's cert).  This enhancement is
required so that the recipient can determine the context of the signer's
signature by examining the cert path of the signer's cert.  This issue
requires further debate on the list.

It was agreed that the SIGATTR text would not be incorporated into CMS until
all issues are resolved.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CERTDIST Draft Discussion - Jim Schaad

Jim stated that the 6 July 98 Certificate Distribution (CERTDIST) I-D has
been submitted to the S/MIME WG mail list.  Jim stated that the open issues
identified include:

1) Lack of content within the published message.  He considers this one
closed and that there will not be a content.  

2) Ability of CA and RA to publishing information on behalf of the user.
Through discussion with others, he has determined that the best solution
requires an extension in the RA's cert.  Issue: Is this overly broad for CAs
to issue?  Jim's current position is that only users can create these messages. 

Issue:  Is the fact that any parent CA could issue this and the fact that a
new Extension is required a problem.  Jim's current position is that the
risks out-weigh the benefits and that only users can create these messages.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

DOMSEC Draft Discussion - Bill Ottaway

Bill stated that the 15 July 98 Domain Security Services using S/MIME
(DOMSEC) I-D has been submitted to the S/MIME WG mail list.  When asked how
many people had read the DOMSEC I-D, many in the room raised their hands.
Bill presented the briefing slides stored on ftp://ftp.ietf.org/ietf/smime/.
These slides presented the basic points made in the DOMSEC I-D.  There were
no significant issues raised.  The question was asked from the floor (by
Paul Hoffman) as to the future plans for the document.  Bill said he was
happy to allow the working group to make that decision.  Paul said that the
DOMSEC I-D contained protocol, so it could not be progressed as an
informational document.  Chris Bonatti suggested that the protocol could be
moved into CMS, allowing the document to become informational.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Revocation Info in CMS - Paul Hoffman

Paul proposed that the message originator should be able to include non-CRL
revocation status information in the CMS heading "in case the recipient of
the message cannot (or does not want to) get the status information when
validating the signature, such as if the recipient is not online and no
usable CRLs were included in the SignedData."  For example, an OCSP response
could be included in the CMS heading.  This could be done via a new
attribute or by enhancing the CMS CRL list syntax.  This proposal requires
further debate on the list. 


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Wrap Up - Russ Housley

Russ asked for a straw poll of the attendees regarding which options the WG
should continue to pursue regarding the "mandatory-to-implement" KM issue.
The results are as follows:

1) Pursue S-S D-H option: about 20 hands raised

2) Pursue E-S D-H option: about 50 hands raised

3) Pursue self-signed E-S- D-H option: 0 hands raised

Based on this straw poll, options 1 and 2 will be pursued in parallel.  Russ
will investigate whether there are any patent issues with the E-S D-H
option.    Russ asked Tim Dierks to post further info regarding the Certicom
license offer.

======================================================
John Pawling                         [e-mail]

J.G. Van Dyke & Associates, Inc.     www.jgvandyke.com       
======================================================




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22628 for ietf-smime-bks; Fri, 18 Sep 1998 08:49:27 -0700 (PDT)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22624; Fri, 18 Sep 1998 08:49:25 -0700 (PDT)
Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (2.0.4/SMS 2.0.4) with ESMTP id JAA24473; Fri, 18 Sep 1998 09:55:26 -0600
From: Steve Hole <[e-mail]>
Date: Fri, 18 Sep 1998 09:55:19 -0600
To: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> "Your message dated Thu, 17 Sep 1998 12:14:46 -0700" <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: Simeon for Win32 Version Mercury a8+ Build (13)
MIME-Version: 1.0
Content-Type: Multipart/signed; BOUNDARY=Part9809180955.F; protocol="application/pgp-signature"; micalg=pgp-sha1
Sender: [e-mail]
Precedence: bulk

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


On Thu, 17 Sep 1998 15:47:36 -0700 (PDT) Ned Freed <[e-mail]>
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:[e-mail]  
Phone:[phone]

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

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.1.1 (C) 1997 Pretty Good Privacy, Inc. (Diffie-Helman/DSS-only version)

iQA/AwUBNgKCa9i5Jj9Fn5KMEQL9TQCeMIoS1oWmLI78DdHpMmI7RwP4XfAAn0XW
R/tXWkOISSxo7q9czbLITPPZ
=gcCK
-----END PGP SIGNATURE-----

--Part9809180955.F--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22114 for ietf-smime-bks; Fri, 18 Sep 1998 07:51:27 -0700 (PDT)
Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA22108 for <[e-mail]>; Fri, 18 Sep 1998 07:51:26 -0700 (PDT)
Received: (qmail 4218 invoked from network); 18 Sep 1998 14:57:25 -0000
Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 18 Sep 1998 14:57:25 -0000
Received: (qmail 18570 invoked from network); 18 Sep 1998 14:57:20 -0000
Received: from tdean.eris.dera.gov.uk (HELO tdean) (128.98.10.5) by mail-relay.eris.dera.gov.uk with SMTP; 18 Sep 1998 14:57:20 -0000
Received: by localhost with Microsoft MAPI; Fri, 18 Sep 1998 15:48:41 +0100
Message-ID: <[e-mail]>
From: Tim Dean <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: Dr Stephen Henson <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: Countersignature Attribute
Date: Fri, 18 Sep 1998 15:48:40 +0100
Organization: DERA
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Steve et al,

>Maybe something more explicit could be included? For example an
>additional signed attribute in the countersignature to indicate that the
>original content had been examined?

You are right: the decision of whether or not to check signatures on 
countersigning obviously depends on the reason for adding the countersignature. 
 Therefore, I support your suggestion.  One possibility would be to move the 
signature type attribute definition from draft-ietf-smime-domsec-00.txt into 
CMS.  Some additional text would be needed in CMS which says that for each 
value of this attribute, it must be stated whether or not the original 
signature was checked.

Thoughts?

____________________________________
Tim Dean
DERA
E-mail: [e-mail]
Web: http://www.dera.gov.uk/
____________________________________


----------
From: 	Russ Housley[SMTP:[e-mail]]
Sent: 	Friday, September 18, 1998 1:32 AM
To: 	Dr Stephen Henson
Cc: 	[e-mail]
Subject: 	Re: Countersignature Attribute

Steve:

How do you know that the signature value being counter-signed has anything
to do with the content if you skip this step?

I agree that the signer cert path does not need to be validated to ensure
that the appropraite binding...

Russ

At 10:55 PM 9/15/98 +0100, Dr Stephen Henson wrote:
>Russ Housley wrote:
>>
>>      The fact that a countersignature is computed on a signature value
>>      means that the countersigning process need not know the original
>>      content input to the signing process.  This might have efficiency
>>      advantages, but it also has security disadvantages.  Therefore,
>>      countersigners must validate the signature value prior to signing
>>      it.  This validation requires processing of the original content.
>>
>
>I respectfully disagree that it should be made mandatory for a
>countersigner to process the original content. IMHO it should depend on
>the purpose of the countersignature which is itself related to the
>policy of the signing authority.
>
>In particular take the example of a trusted timestamp. The purpose of
>such a countersignature is simply to state that a a given signature
>existed at a given time. It says absolutely nothing about the content
>being signed. It has a definite and valuable purpose for nonrepudiation.
>
>It can for example show that a document was signed during the validity
>period of the signer's certificate and is thus useful fot archiving
>purposes and others related to software publishing.
>
>In for example a large and confidential document a client would simply
>pass its digital signature to the timestamper. If the content needs to
>be analysed then large amounts of possibly confidential data would need
>to be passed to the timestamper. This is undesirable both in terms of
>security and increased load on the countersigner.
>
>Of course if the countersignature is to have some additional value then
>having access to the content does become important.
>
>Steve.
>--
>Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
>For info see homepage at http://www.drh-consultancy.demon.co.uk/
>Email: [e-mail]
>PGP key: via homepage.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21942 for ietf-smime-bks; Fri, 18 Sep 1998 07:23:18 -0700 (PDT)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA21938 for <[e-mail]>; Fri, 18 Sep 1998 07:23:17 -0700 (PDT)
Received: from mail.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 18 Sep 1998 14:28:38 UT
Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id KAA25882; Fri, 18 Sep 1998 10:34:25 -0400 (EDT)
Received: by exna01.securitydynamics.com with Internet Mail Service (5.0.1460.8) id <RT690ZS6>; Fri, 18 Sep 1998 10:32:30 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "Linn, John" <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Proposed CMS security considerations re PKCS #1
Date: Fri, 18 Sep 1998 10:30:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Russ:

Thanks for incorporating the material.  This looks generally good; I'd like
to suggest two clarifications and fix one typo, embedded below:

> ----------
> From: 	Russ Housley[SMTP:[e-mail]]
> Sent: 	Thursday, September 17, 1998 1:42 PM
> To: 	[e-mail]
> Cc: 	[e-mail]
> Subject: 	Re: Proposed CMS security considerations re PKCS #1
> 
> John:
> 
> Thanks for the contribution.  I made a few chanes to make the words flow
> with
> the rest of the Security Considerations section.  PLease let me know if I
> messed anything up in the process.
> 
> Russ
> 
> 
> [inserted in CMS Security considerations]
> 
> Users of CMS, particularly those employing CMS to support interactive
> applications, should be aware that PKCS #1 [RFC 2313] is vulnerable to
> adaptive
> chosen ciphertext attacks when applied for encryption purposes.
> Exploitation
> of this identified vulnerability, revealing the result of a particular RSA
> decryption, requires access to an oracle which will respond to a large
> number
> of ciphertexts (perhaps hundreds of thousands)
> 
Suggest replacing "(perhaps hundreds of thousands)" with "(based on
currently available results, hundreds of thousands or more)".

> , which are constructed
> adaptively in response to previously-received replies providing
> information on
> the results 
> 
Consistent with the second paragraph, I suggest changing "the results" to
"the successes or failures"; sorry for not already having framed this
sentence in this fashion. 

> of attempted decryption operations.  As a result, the attack
> appears significantly less feasible to perpetrate for store-and-forward
> S/MIME
> environments than for directly interactive protocols.  Where CMS
> constructs
> are
> applied as an intermediate encryption layer within an interactive
> request-response communications environment, exploitation could be more
> feasible.
> 
> An updated version of PKCS #1 has been published as an Internet-Draft, and
> the
> new document is targeted to become PKCS #1 Version 2.0 and to succeed RFC
> 2313.  To resolve the adaptive chosen ciphertext vulnerability, the new
> document specifies and recommends use of Optimal Asymmetric Encryption
> Padding
> (OAEP) when RSA encryption is applied to provide secrecy.  Designers of
> protocols and systems employing CMS for interactive environments should
> either
> consider usage of OAEP, or should ensure that information which could
> reveal
> the success or failure of attempted PKCS #1 decryption operations
> in not
> 
Typo: "in not" -> "is not".

> provided.  Support for OAEP may be added to a future version of the CMS
> specification once the PKCS#1 Version 2.0 is stable.
> 
--jl



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21632 for ietf-smime-bks; Fri, 18 Sep 1998 06:33:48 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21628 for <[e-mail]>; Fri, 18 Sep 1998 06:33:47 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id GAA13183; Fri, 18 Sep 1998 06:39:14 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Thu, 17 Sep 1998 13:42:55 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Proposed CMS security considerations re PKCS #1
Cc: [e-mail]
In-Reply-To: <[e-mail] mics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

John:

Thanks for the contribution.  I made a few chanes to make the words flow with
the rest of the Security Considerations section.  PLease let me know if I
messed anything up in the process.

Russ


[inserted in CMS Security considerations]

Users of CMS, particularly those employing CMS to support interactive
applications, should be aware that PKCS #1 [RFC 2313] is vulnerable to
adaptive
chosen ciphertext attacks when applied for encryption purposes.  Exploitation
of this identified vulnerability, revealing the result of a particular RSA
decryption, requires access to an oracle which will respond to a large number
of ciphertexts (perhaps hundreds of thousands), which are constructed
adaptively in response to previously-received replies providing information on
the results of attempted decryption operations.  As a result, the attack
appears significantly less feasible to perpetrate for store-and-forward S/MIME
environments than for directly interactive protocols.  Where CMS constructs
are
applied as an intermediate encryption layer within an interactive
request-response communications environment, exploitation could be more
feasible.

An updated version of PKCS #1 has been published as an Internet-Draft, and the
new document is targeted to become PKCS #1 Version 2.0 and to succeed RFC
2313.  To resolve the adaptive chosen ciphertext vulnerability, the new
document specifies and recommends use of Optimal Asymmetric Encryption Padding
(OAEP) when RSA encryption is applied to provide secrecy.  Designers of
protocols and systems employing CMS for interactive environments should either
consider usage of OAEP, or should ensure that information which could reveal
the success or failure of attempted PKCS #1 decryption operations in not
provided.  Support for OAEP may be added to a future version of the CMS
specification once the PKCS#1 Version 2.0 is stable.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21624 for ietf-smime-bks; Fri, 18 Sep 1998 06:33:44 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21620 for <[e-mail]>; Fri, 18 Sep 1998 06:33:43 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id GAA13179; Fri, 18 Sep 1998 06:39:10 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Thu, 17 Sep 1998 13:01:28 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: ASN.1-SIZE floating
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Peter:

I would like to support multiple name forms.  RFC 822 Addresses and X.500
Distinguished names both have uses.

I can agree to limiting to maximun number of GeneralNames in the sequence
to some small number, but not one.  Perhaps eight is a reasonable number.

Russ


At 09:49 AM 9/16/98 +0000, Peter Gutmann wrote:
>[e-mail] (John Pawling) writes:
> 
>>MLReceiptPolicy ::= CHOICE {
>>  none [0] NULL,
>>  insteadOf [1] SEQUENCE SIZE (1..64) OF GeneralNames,
>>  inAdditionTo [2] SEQUENCE SIZE (1..64) OF GeneralNames }
> 
>Since GeneralNames is already a SEQUENCE SIZE (1...someone-elses-MAX) OF 
>GeneralName, shouldn't these fields be GeneralName (without the 's')?  
>Alternatively, just use GeneralNames (without the SEQUENCE OF), since it's 
>already defined elsewhere.  This problem (using GeneralNames instead of 
>GeneralName) occurs in various other places as well...
> 
>While I'm commenting on MLReceiptPolicy, the tagging on the NULL isn't 
>necessary, since it's distinct from the two SEQUENCEs - all you need is [0] 
>and [1] to distinguish the SEQUENCEs.
> 
>Peter.
> 
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21160 for ietf-smime-bks; Fri, 18 Sep 1998 05:20:45 -0700 (PDT)
Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21154; Fri, 18 Sep 1998 05:20:41 -0700 (PDT)
Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with SMTP id NAA17018; Fri, 18 Sep 1998 13:26:37 +0100 (BST)
Message-ID: <[e-mail]>
Date: Fri, 18 Sep 1998 13:24:02 +0100
To: [e-mail], [e-mail]
From: Ian Bell <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
References: <hmnp$QAJ5NA2IA$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike (32) Version 4.00  <U2yaxlNz9mbtXQDcM+J3SutElj>
Sender: [e-mail]
Precedence: bulk

In article <[e-mail]>, Ned Freed
<[e-mail]> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA08468 for ietf-smime-bks; Thu, 17 Sep 1998 22:55:57 -0700 (PDT)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA08263; Thu, 17 Sep 1998 22:54:15 -0700 (PDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]>; Thu, 17 Sep 1998 22:59:08 PDT
Date: Thu, 17 Sep 1998 22:55:50 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-reply-to: "Your message dated Thu, 17 Sep 1998 17:20:09 -0700" <v04101908b227569e6d17@[129.46.172.254]>
To: "John  W. Noerenberg" <[e-mail]>
Cc: Ned Freed <[e-mail]>, Hal Finney <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA06262 for ietf-smime-bks; Thu, 17 Sep 1998 22:27:53 -0700 (PDT)
Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA06256; Thu, 17 Sep 1998 22:27:51 -0700 (PDT)
Received: from anonymous (slip129-37-235-151.ca.us.ibm.net [129.37.235.151]) by out1.ibm.net (8.8.5/8.6.9) with ESMTP id FAA08378; Fri, 18 Sep 1998 05:33:51 GMT
Message-Id: <[e-mail]>
From: "Tom Phinney" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Date: Thu, 17 Sep 1998 22:33:07 -0700
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

From: [e-mail]

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA03073 for ietf-smime-bks; Thu, 17 Sep 1998 21:55:48 -0700 (PDT)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA03069; Thu, 17 Sep 1998 21:55:46 -0700 (PDT)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA27879; Fri, 18 Sep 1998 14:01:08 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA07769; Fri, 18 Sep 1998 14:01:07 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA22374; Fri, 18 Sep 1998 14:01:07 +0900 (JST)
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: Your message of "Thu, 17 Sep 1998 11:02:49 +0100" <hmnp$QAJ5NA2IA$[e-mail]>
References: <hmnp$QAJ5NA2IA$[e-mail]>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Fri, 18 Sep 1998 13:00:21 +0900
X-Dispatcher: imput version 980905(IM100)
Lines: 28
Sender: [e-mail]
Precedence: bulk

Ian,

From: Ian Bell <[e-mail]>
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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA28033 for ietf-smime-bks; Thu, 17 Sep 1998 18:46:58 -0700 (PDT)
Received: from candle.brasslantern.com ([e-mail] [206.155.48.241]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA28029; Thu, 17 Sep 1998 18:46:52 -0700 (PDT)
Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id SAA02549; Thu, 17 Sep 1998 18:51:45 -0700
From: "Bart Schaefer" <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 17 Sep 1998 18:51:45 -0700
In-Reply-To: <v04101908b227569e6d17@[129.46.172.254]>
Comments: In reply to "John  W. Noerenberg" <[e-mail]> "Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages" (Sep 17,  5:20pm)
References: "Your message dated Thu  17 Sep 1998 12:14:46 -0700" <[e-mail]>  <v04101908b227569e6d17@[129.46.172.254]>
X-Mailer: Z-Mail (4.0b.820 20aug96)
To: "John  W. Noerenberg" <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA27543 for ietf-smime-bks; Thu, 17 Sep 1998 17:22:29 -0700 (PDT)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA27539; Thu, 17 Sep 1998 17:22:28 -0700 (PDT)
Received: from [129.46.172.254] (jnoerenberg-mac.qualcomm.com [129.46.172.254]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA24259; Thu, 17 Sep 1998 17:27:12 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Sender: [e-mail]
Message-Id: <v04101908b227569e6d17@[129.46.172.254]>
In-Reply-To: <[e-mail]>
References: "Your message dated Thu, 17 Sep 1998 12:14:46 -0700" <[e-mail]>
X-Mailer: Eudora [Macintosh version 4.1b25-10.98]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Thu, 17 Sep 1998 17:20:09 -0700
To: Ned Freed <[e-mail]>
From: "John  W. Noerenberg" <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: Hal Finney <[e-mail]>, [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
  ----------------------------------------------------------------------
  --if we are to be saved, it will not be by Romans but by saints.
  -- Thomas Cahill, "how the Irish Saved Civilization", 1995
  ----------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27149 for ietf-smime-bks; Thu, 17 Sep 1998 16:38:01 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA27130; Thu, 17 Sep 1998 16:36:19 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Thu, 17 Sep 1998 16:41:48 -0700
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-Reply-To: <[e-mail]>
References: <"Your message dated Thu, 17 Sep 1998 12:14:46 -0700" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA26894 for ietf-smime-bks; Thu, 17 Sep 1998 16:11:09 -0700 (PDT)
Received: from candle.brasslantern.com ([e-mail] [206.155.48.241]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26890; Thu, 17 Sep 1998 16:11:00 -0700 (PDT)
Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id QAA02063; Thu, 17 Sep 1998 16:16:44 -0700
From: "Bart Schaefer" <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 17 Sep 1998 16:16:44 -0700
In-Reply-To: <[e-mail]>
Comments: In reply to Ned Freed <[e-mail]> "Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages" (Sep 17,  3:47pm)
References: <[e-mail]>
X-Mailer: Z-Mail Lite (5.0.0 30July97)
To: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA26711 for ietf-smime-bks; Thu, 17 Sep 1998 15:49:07 -0700 (PDT)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA26691; Thu, 17 Sep 1998 15:47:22 -0700 (PDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]>; Thu, 17 Sep 1998 15:52:20 PDT
Date: Thu, 17 Sep 1998 15:47:36 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-reply-to: "Your message dated Thu, 17 Sep 1998 12:14:46 -0700" <[e-mail]>
To: Hal Finney <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25744 for ietf-smime-bks; Thu, 17 Sep 1998 13:37:19 -0700 (PDT)
Received: from coyote.rain.org ([e-mail] [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25717; Thu, 17 Sep 1998 13:33:47 -0700 (PDT)
Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.1/8.9.1) with ESMTP id NAA24579; Thu, 17 Sep 1998 13:37:11 -0700 (PDT)
Received: (from hal@localhost) by hal.sb.rain.org (8.7.4/8.7.3) id MAA01954; Thu, 17 Sep 1998 12:14:46 -0700
Date: Thu, 17 Sep 1998 12:14:46 -0700
From: Hal Finney <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24500 for ietf-smime-bks; Thu, 17 Sep 1998 11:14:28 -0700 (PDT)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24462; Thu, 17 Sep 1998 11:12:29 -0700 (PDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]>; Thu, 17 Sep 1998 11:17:51 PDT
Date: Thu, 17 Sep 1998 11:04:15 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-reply-to: "Your message dated Thu, 17 Sep 1998 11:02:49 +0100" <hmnp$QAJ5NA2IA$[e-mail]>
To: Ian Bell <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22947 for ietf-smime-bks; Thu, 17 Sep 1998 08:12:19 -0700 (PDT)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22942 for <[e-mail]>; Thu, 17 Sep 1998 08:12:14 -0700 (PDT)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id LAA20410; Thu, 17 Sep 1998 11:17:04 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 17 Sep 1998 11:14:48 -0400
To: Dr Stephen Henson <[e-mail]>
From: Francois Rousseau <[e-mail]>
Subject: Re: Countersignature Attribute
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Steve wrote:
>
>Maybe something more explicit could be included? For example an
>additional signed attribute in the countersignature to indicate that the
>original content had been examined?
>
If I am not mistaken, the EDI assurance segments from ANSI X12.58 contains
such a parameter (i.e. Domain_of_Computation_of_Assurance_Digest) to
indicate the scope of the digital signature.

Francois Rousseau


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22234 for ietf-smime-bks; Thu, 17 Sep 1998 06:27:01 -0700 (PDT)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA22230 for <[e-mail]>; Thu, 17 Sep 1998 06:27:00 -0700 (PDT)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.03 #1) id 0zJeB3-0001eH-00; Thu, 17 Sep 1998 13:32:53 +0000
Message-ID: <[e-mail]>
Date: Thu, 17 Sep 1998 14:30:15 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Countersignature Attribute
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Russ Housley wrote:
> 
> Steve:
> 
> How do you know that the signature value being counter-signed has anything
> to do with the content if you skip this step?
> 

You don't: they could just be getting random data countersigned that
isn't the signature to anything. 

If the client can't verify the original signature they can't rely on the
countersignature. At best it could see that the digital signature being
countersigned is a signature of "something" though not what it referred
to. It may or may not refer to some valid content.

A similar case could arise even if the countersigner does verify the
original content and it was for example corrupted in transit. In this
case the client could make the conclusion that some content was
countersigned they would just have no idea what it was.

IMHO the only real difference between the two is that without content
verification an arbitrary digest could be countersigned whereas with
content verification it would have to be a digest to some known content.

I'm not sure what additional tricks could be played with content
verification but without chain verification: since bogus certificate
chains with arbitrary public keys could be included.

In the case of a timestamp none of this matters. 

IMHO there are serious practical, security and privacy issues involved
if content has to always be examined by the countersigner, particularly
in the case of a timestamping authority.

In this case the countersigning certificate may well (should?) contain
appropriate extensions to indicate that it is a timestamping authority.

Maybe something more explicit could be included? For example an
additional signed attribute in the countersignature to indicate that the
original content had been examined?

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21948 for ietf-smime-bks; Thu, 17 Sep 1998 05:36:59 -0700 (PDT)
Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21944; Thu, 17 Sep 1998 05:36:57 -0700 (PDT)
Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with SMTP id NAA01244; Thu, 17 Sep 1998 13:42:48 +0100 (BST)
Message-ID: <[e-mail]>
Date: Thu, 17 Sep 1998 13:40:49 +0100
To: [e-mail], [e-mail]
From: Ian Bell <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike (32) Version 4.00  <U2yaxlNz9mbtXQDcM+J3SutElj>
Sender: [e-mail]
Precedence: bulk

In article <[e-mail]>, Lindsay Mathieson
<[e-mail]> 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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA21637 for ietf-smime-bks; Thu, 17 Sep 1998 04:45:33 -0700 (PDT)
Received: from atlas.arc.nasa.gov (atlas.arc.nasa.gov [198.123.9.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA21633 for <[e-mail]>; Thu, 17 Sep 1998 04:45:32 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (207-172-112-203.s203.tnt4.ann.erols.com [207.172.112.203]) by atlas.arc.nasa.gov (8.8.5/8.7.3/arc) with SMTP id EAA03804; Thu, 17 Sep 1998 04:51:24 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Thu, 17 Sep 1998 20:32:05 -0400
To: Dr Stephen Henson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Countersignature Attribute
Cc: "[e-mail]" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Steve:

How do you know that the signature value being counter-signed has anything
to do with the content if you skip this step?

I agree that the signer cert path does not need to be validated to ensure
that the appropraite binding...

Russ

At 10:55 PM 9/15/98 +0100, Dr Stephen Henson wrote:
>Russ Housley wrote:
>> 
>>      The fact that a countersignature is computed on a signature value
>>      means that the countersigning process need not know the original
>>      content input to the signing process.  This might have efficiency
>>      advantages, but it also has security disadvantages.  Therefore,
>>      countersigners must validate the signature value prior to signing
>>      it.  This validation requires processing of the original content.
>> 
>
>I respectfully disagree that it should be made mandatory for a
>countersigner to process the original content. IMHO it should depend on
>the purpose of the countersignature which is itself related to the
>policy of the signing authority.
>
>In particular take the example of a trusted timestamp. The purpose of
>such a countersignature is simply to state that a a given signature
>existed at a given time. It says absolutely nothing about the content
>being signed. It has a definite and valuable purpose for nonrepudiation.
>
>It can for example show that a document was signed during the validity
>period of the signer's certificate and is thus useful fot archiving
>purposes and others related to software publishing.
>
>In for example a large and confidential document a client would simply
>pass its digital signature to the timestamper. If the content needs to
>be analysed then large amounts of possibly confidential data would need
>to be passed to the timestamper. This is undesirable both in terms of
>security and increased load on the countersigner.
>
>Of course if the countersignature is to have some additional value then
>having access to the content does become important.
>
>Steve.
>-- 
>Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
>For info see homepage at http://www.drh-consultancy.demon.co.uk/
>Email: [e-mail]
>PGP key: via homepage.
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA19312 for ietf-smime-bks; Thu, 17 Sep 1998 02:59:33 -0700 (PDT)
Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA19308; Thu, 17 Sep 1998 02:59:31 -0700 (PDT)
Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with SMTP id LAA21050; Thu, 17 Sep 1998 11:05:16 +0100 (BST)
Message-ID: <hmnp$QAJ5NA2IA$[e-mail]>
Date: Thu, 17 Sep 1998 11:02:49 +0100
To: [e-mail], [e-mail]
From: Ian Bell <[e-mail]>
Subject: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
MIME-Version: 1.0
X-Mailer: Turnpike (32) Version 4.00  <U2yaxlNz9mbtXQDcM+J3SutElj>
Sender: [e-mail]
Precedence: bulk

(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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25311 for ietf-smime-bks; Wed, 16 Sep 1998 12:23:38 -0700 (PDT)
Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25307 for <[e-mail]>; Wed, 16 Sep 1998 12:23:34 -0700 (PDT)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <RBDL7S68>; Wed, 16 Sep 1998 12:29:27 -0700
Message-ID: <2FBF98FC7852CF11912A000000000001091266F0@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Dr Stephen Henson'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Countersignature Attribute
Date: Wed, 16 Sep 1998 12:28:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

At Steve's suggestion I looked through the CAPI code which has shipped on NT
and found the following.  (Please not this is not used by any of the mail
products today but exists in public APIs).

1.  There may be multiple counter signature attributes in the
unauthencticated attributes (no enforement otherwise and no implicit relying
on one attribute in the code).

2.  There may be multiple counter signature values within a single
attribute.

jim

-----Original Message-----
From: Dr Stephen Henson [mailto:[e-mail]]
Sent: Tuesday, September 15, 1998 3:03 PM
To: Jim Schaad (Exchange)
Cc: [e-mail]
Subject: Re: Countersignature Attribute


Jim Schaad (Exchange) wrote:
> 
> I don't know about other products, but Outlook and OE tooke the approach
of
> ignoring countersignatures.
> 

Jim, 

I seem to recall there are functions in MS CryptoAPI for adding
countersignatures. I haven't used them myself but can you comment on
whether multiple countersignatures can be added and if so what format it
uses?

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA21067 for ietf-smime-bks; Wed, 16 Sep 1998 08:29:16 -0700 (PDT)
Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA21063 for <[e-mail]>; Wed, 16 Sep 1998 08:29:14 -0700 (PDT)
Received: (qmail 7243 invoked from network); 16 Sep 1998 15:35:01 -0000
Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 16 Sep 1998 15:35:01 -0000
Received: (qmail 6788 invoked from network); 16 Sep 1998 15:34:57 -0000
Received: from wottoway.eris.dera.gov.uk (HELO wottaway.eris.dera.gov.uk) (128.98.10.17) by mail-relay.eris.dera.gov.uk with SMTP; 16 Sep 1998 15:34:57 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 16 Sep 1998 16:34:19 +0100
To: [e-mail]
From: William Ottaway <[e-mail]>
Subject: Has anyone sent me mail during 4 sept 98 to 14 sept 98
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Hi all,

Due to my data disk getting trashed when I arrived back from holiday I have
lost all email sent to me from 4th Sept 1998 to 14th Sept 1998. If any of
you have sent email directly to me during this period can you please resend
it. I'll get email sent to the list from the archive.

Cheers in advance.

Bill
________________________________________________________________
William Ottaway,
L323,                        Tel: [phone]
DERA Malvern,                Fax: [phone]
St. Andrews Road,            email: [e-mail]
Malvern,
Worcs,
WR14 3PS



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA20949 for ietf-smime-bks; Wed, 16 Sep 1998 08:16:55 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA20945 for <[e-mail]>; Wed, 16 Sep 1998 08:16:54 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id LAA24540 for <[e-mail]>; Wed, 16 Sep 1998 11:26:22 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id LAA00723; Wed, 16 Sep 1998 11:24:55 -0400
Date: Wed, 16 Sep 1998 11:24:55 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: RE: Countersignature Attribute
Sender: [e-mail]
Precedence: bulk

Russ (and friends),

I have two comments to your proposal:

1) I believe that Stephen Hanson's comments should be addressed.  In an
earlier message exchange regarding countersignatures, the recommendation was
to allow a countersigner to calculate the contersignature without requiring
validation of the original signature.  Paul Hoffman recommended that the
following text be added to CMS (except that I corrected his last sentence
based on Bill Ottaway's comment):

A countersignature can be created without the countersigner knowing the
original content. The recipient who is validating the countersignature has
no way of knowing if the signature that was countersigned is valid without
checking that signature as well. Thus, a recipient who can validate a
countersignature but cannot validate the original signature must not infer
that the content that was signed has not been modified, and must not infer
that the countersigner actually had access to the content.


2) Your proposal states that there can be multiple countersignature
attributes in a signerInfo UnsignedAttributes SET OF Attributes.  I am not
strongly opposed to your proposal, but the countersignature would be the
only attribute type for which multiple instances would be permitted.  This
may be confusing to the implementors since all of the other attribute types
are limited to 0 or 1 instances.  I believe that it would be beneficial to
state a rule limiting the number of countersignature attributes to 0 or 1.
This would be consistent with the processing rules for all of the other
attributes. 

- John Pawling




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA19134 for ietf-smime-bks; Wed, 16 Sep 1998 05:43:52 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA19130 for <[e-mail]>; Wed, 16 Sep 1998 05:43:51 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id IAA23547 for <[e-mail]>; Wed, 16 Sep 1998 08:53:18 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id IAA28588; Wed, 16 Sep 1998 08:51:53 -0400
Date: Wed, 16 Sep 1998 08:51:53 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: Re: ASN.1-SIZE floating
Sender: [e-mail]
Precedence: bulk

All,

Darren is correct, the MLReceiptPolicy insteadOf and inAdditionTo fields
must each be a SEQUENCE OF GeneralNames (not GeneralName) in order for
S/MIME to provide functionality that is equivalent to MSP and ACP120.  Each
GeneralNames represents an entity to which the S/MIME message recipient
should send a signed receipt, if appropriate.  To represent an entity's
O/RName in which both the ORAddress and DN are present, the GeneralNames
SEQUENCE will contain one GeneralName with the entity's x400Address present
followed by another GeneralName with the entity's directoryName present.

================================
John Pawling, [e-mail]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA04651 for ietf-smime-bks; Tue, 15 Sep 1998 23:01:53 -0700 (PDT)
Received: from access.itsec.gov.uk (access.itsec.gov.uk [193.195.170.254]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA04643 for <[e-mail]>; Tue, 15 Sep 1998 23:01:50 -0700 (PDT)
Received: by access.itsec.gov.uk; id AA22431; Wed, 16 Sep 98 06:56:52 BST
Received: from ingress.itsec.dmz(192.168.1.250) by access.itsec.gov.uk via smap (3.2) id xma022423; Wed, 16 Sep 98 06:56:50 +0100
Received: by ingress.itsec.dmz; id AA17036; Wed, 16 Sep 98 06:57:59 BST
Received: from sleepy.itsec.lepernet(10.10.10.25) by ingress.itsec.dmz via smap (3.2) id xma017024; Wed, 16 Sep 98 06:57:48 +0100
Received: from CESG-Message_Server by cesg.gov.uk with Novell_GroupWise; Wed, 16 Sep 1998 06:57:54 +0100
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.2
Date: Wed, 16 Sep 1998 07:03:51 +0100
From: "Darren Harter" <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: ASN.1-SIZE floating
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id XAA04647
Sender: [e-mail]
Precedence: bulk

Peter,

The use of GeneralNames originates from this field's use in MSP.  Originally ORName was used, and when the MSP implementors board discussed replacing ORName with GeneralName, I suggested that GeneralNames be used instead for the following reason.

ORName is (IIRC) a SEQUENCE of an OPTIONAL Name and an OPTIONAL ORAddress.  Whereas GeneralName is a simple CHOICE that includes Name and ORAddress as options.

This meant that an existing application that relied on both optional elements of the ORName would not be able to work with GeneralName. The only way to allow these applications to work would be to use GeneralNames.

So all occurences of ORName in MSP were replaced with GeneralNames.  Clearly the bits on the wire changed due to the tags in the GeneralName CHOICE, but the semantics for previous ORName functionality were retained.

I agree with you that for S/MIME in the pure Internet community GeneralName should be acceptable, but CMS and ESS go way beyond S/MIME.  They are being implemented in X.400 environments and full support for ORName fields is therefore necessary, IMO.

Darren

Darren Harter
CASM Programme Office
CESG
[e-mail]

>>> Peter Gutmann <[e-mail]> 09/16/98 09:49am >>>
Since GeneralNames is already a SEQUENCE SIZE (1...someone-elses-MAX) OF 
GeneralName, shouldn't these fields be GeneralName (without the 's')?  
Alternatively, just use GeneralNames (without the SEQUENCE OF), since it's 
already defined elsewhere.  This problem (using GeneralNames instead of 
GeneralName) occurs in various other places as well...
 
While I'm commenting on MLReceiptPolicy, the tagging on the NULL isn't 
necessary, since it's distinct from the two SEQUENCEs - all you need is [0] 
and [1] to distinguish the SEQUENCEs.
 
Peter.
 




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA23058 for ietf-smime-bks; Tue, 15 Sep 1998 20:14:03 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA23054 for <[e-mail]>; Tue, 15 Sep 1998 20:13:50 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id PAA11612 for <[e-mail]>; Wed, 16 Sep 1998 15:19:30 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90591597017692>; Wed, 16 Sep 1998 15:19:30 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Countersignature Attribute
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 16 Sep 1998 15:19:30 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Russ Housley <[e-mail]> writes:
 
>A countersignature attribute can have multiple attribute values.  The syntax 
>is defined as a SET OF AttributeValue, and there must be one or more 
>instances of AttributeValue present.
>
>The UnsignedAttributes syntax is defined as a SET OF Attributes.  The 
>UnsignedAttributes in a signerInfo may include multiple instances of the 
>countersignature attribute.
 
The problem with this is that it leads to ambiguous interpretations of how to 
encode the countersignature (one attribute, one or more values; multiple 
attributes, single value; multiple attributes, multiple values).  The nice 
thing about John's proposal (one attribute, one or more values) is that it's a 
canonical encoding - there's no way individual implementors can misinterpret 
it to produce something different from what everyone else is doing.  Given 
that countersignatures seem to be unused by anyone (or at least anyone who's 
replied so far), using John's more rigorous definition wouldn't seem to cause 
any problems.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA15005 for ietf-smime-bks; Tue, 15 Sep 1998 16:12:36 -0700 (PDT)
Received: from cane.deming.com (cane.deming.com [208.236.41.9] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA15001 for <[e-mail]>; Tue, 15 Sep 1998 16:12:34 -0700 (PDT)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.0.1); Tue, 15 Sep 98 16:18:23 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.1960.3) id <S6KG5JB9>; Tue, 15 Sep 1998 16:18:23 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Jim Schaad (Exchange)'" <[e-mail]>, "'Russ Housley'" <[e-mail]>, <[e-mail]>
cc: <[e-mail]>, <[e-mail]>
Subject: RE: Countersignature Attribute
Date: Tue, 15 Sep 1998 16:18:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
X-WSS-ID: 19E02A3514386-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Jim Schaad (Exchange) [mailto:[e-mail]]
> Sent: Tuesday, September 15, 1998 2:41 PM
> To: 'Russ Housley'; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: Countersignature Attribute
> 
> I don't know about other products, but Outlook and OE tooke 
> the approach of
> ignoring countersignatures.

Mmm.  Boy.  We ignore them also.  They weren't profiled at all in v2.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14270 for ietf-smime-bks; Tue, 15 Sep 1998 14:59:04 -0700 (PDT)
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14266 for <[e-mail]>; Tue, 15 Sep 1998 14:59:03 -0700 (PDT)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.02 #1) id 0zJ3DQ-00025l-00; Tue, 15 Sep 1998 22:04:52 +0000
Message-ID: <[e-mail]>
Date: Tue, 15 Sep 1998 23:02:58 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "Jim Schaad (Exchange)" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Countersignature Attribute
References: <2FBF98FC7852CF11912A000000000001091266ED@DINO>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Jim Schaad (Exchange) wrote:
> 
> I don't know about other products, but Outlook and OE tooke the approach of
> ignoring countersignatures.
> 

Jim, 

I seem to recall there are functions in MS CryptoAPI for adding
countersignatures. I haven't used them myself but can you comment on
whether multiple countersignatures can be added and if so what format it
uses?

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14235 for ietf-smime-bks; Tue, 15 Sep 1998 14:53:08 -0700 (PDT)
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14231 for <[e-mail]>; Tue, 15 Sep 1998 14:53:07 -0700 (PDT)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.02 #1) id 0zJ37g-0001gD-00 for [e-mail]; Tue, 15 Sep 1998 21:58:56 +0000
Message-ID: <[e-mail]>
Date: Tue, 15 Sep 1998 22:55:16 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: Countersignature Attribute
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Russ Housley wrote:
> 
>      The fact that a countersignature is computed on a signature value
>      means that the countersigning process need not know the original
>      content input to the signing process.  This might have efficiency
>      advantages, but it also has security disadvantages.  Therefore,
>      countersigners must validate the signature value prior to signing
>      it.  This validation requires processing of the original content.
> 

I respectfully disagree that it should be made mandatory for a
countersigner to process the original content. IMHO it should depend on
the purpose of the countersignature which is itself related to the
policy of the signing authority.

In particular take the example of a trusted timestamp. The purpose of
such a countersignature is simply to state that a a given signature
existed at a given time. It says absolutely nothing about the content
being signed. It has a definite and valuable purpose for nonrepudiation.

It can for example show that a document was signed during the validity
period of the signer's certificate and is thus useful fot archiving
purposes and others related to software publishing.

In for example a large and confidential document a client would simply
pass its digital signature to the timestamper. If the content needs to
be analysed then large amounts of possibly confidential data would need
to be passed to the timestamper. This is undesirable both in terms of
security and increased load on the countersigner.

Of course if the countersignature is to have some additional value then
having access to the content does become important.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14180 for ietf-smime-bks; Tue, 15 Sep 1998 14:43:41 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14176 for <[e-mail]>; Tue, 15 Sep 1998 14:43:39 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id JAA18696 for <[e-mail]>; Wed, 16 Sep 1998 09:49:26 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90589616615256>; Wed, 16 Sep 1998 09:49:26 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: ASN.1-SIZE floating
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 16 Sep 1998 09:49:26 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

[e-mail] (John Pawling) writes:
 
>MLReceiptPolicy ::= CHOICE {
>  none [0] NULL,
>  insteadOf [1] SEQUENCE SIZE (1..64) OF GeneralNames,
>  inAdditionTo [2] SEQUENCE SIZE (1..64) OF GeneralNames }
 
Since GeneralNames is already a SEQUENCE SIZE (1...someone-elses-MAX) OF 
GeneralName, shouldn't these fields be GeneralName (without the 's')?  
Alternatively, just use GeneralNames (without the SEQUENCE OF), since it's 
already defined elsewhere.  This problem (using GeneralNames instead of 
GeneralName) occurs in various other places as well...
 
While I'm commenting on MLReceiptPolicy, the tagging on the NULL isn't 
necessary, since it's distinct from the two SEQUENCEs - all you need is [0] 
and [1] to distinguish the SEQUENCEs.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14126 for ietf-smime-bks; Tue, 15 Sep 1998 14:35:46 -0700 (PDT)
Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14122 for <[e-mail]>; Tue, 15 Sep 1998 14:35:45 -0700 (PDT)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <RBDL72W6>; Tue, 15 Sep 1998 14:41:26 -0700
Message-ID: <2FBF98FC7852CF11912A000000000001091266ED@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: Countersignature Attribute
Date: Tue, 15 Sep 1998 14:41:01 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA14123
Sender: [e-mail]
Precedence: bulk

I don't know about other products, but Outlook and OE tooke the approach of
ignoring countersignatures.
 
jim
 

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Tuesday, September 15, 1998 1:40 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: Countersignature Attribute


John:

Prior to getting this note, I took a stab at revisions to the same section
of text.  I do not know how S/MIME v2 implementations handle
countersignatures, but I took the opposite approach that you did.  I was
trying to ensure that current implemntations would all conform.

Here is what I wrote:


A countersignature attribute can have multiple attribute values.  The syntax
is defined as a SET OF AttributeValue, and there must be one or more
instances of AttributeValue present.



The UnsignedAttributes syntax is defined as a SET OF Attributes.  The
UnsignedAttributes in a signerInfo may include multiple instances of the
countersignature attribute.



The fact that a countersignature is computed on a signature value means that
the countersigning process need not know the original content input to the
signing process.  This might have efficiency advantages, but it also has
security disadvantages.  Therefore, countersigners must validate the
signature value prior to signing it.  This validation requires processing of
the original content.



A countersignature, since it has type SignerInfo, can itself contain a
countersignature attribute.  Thus it is possible to construct arbitrarily
long series of countersignatures.





Russ


At 11:56 AM 9/15/98 -0400, John Pawling wrote:
>Peter (and friends),
>
>I agree with your recommendation.  This results in a change to my comment
to
>CMS-06 to read as follows:
>
>5) Sec 11.4, Countersignature: Please change as follows:
>
>OLD: "A countersignature attribute can have multiple attribute values."
>
>NEW: "The UnsignedAttributes syntax is defined as a SET OF Attribute.  
>The UnsignedAttributes in a signerInfo MUST NOT include multiple 
>instances of the countersignature attribute.  The Attribute syntax defines 
>attrValues as a SET OF AttributeValue.  A countersignature attribute 
>MAY include one or more instances of AttributeValue.  There MUST NOT 
>be zero instances of AttributeValue present in the attrValues SET
>OF AttributeValue."
>
>Does anybody disagree with this recommendation???
>
>- John Pawling
>




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA13789 for ietf-smime-bks; Tue, 15 Sep 1998 13:43:48 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA13785 for <[e-mail]>; Tue, 15 Sep 1998 13:43:47 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id NAA14205; Tue, 15 Sep 1998 13:47:46 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Tue, 15 Sep 1998 16:39:56 -0400
To: [e-mail] (John Pawling)
From: Russ Housley <[e-mail]>
Subject: Re: Countersignature Attribute
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

<html>
John:<br>
<br>
Prior to getting this note, I took a stab at revisions to the same
section of text.&nbsp; I do not know how S/MIME v2 implementations handle
countersignatures, but I took the opposite approach that you did.&nbsp; I
was trying to ensure that current implemntations would all conform.<br>
<br>
Here is what I wrote:<br>
<font face="Courier New, Courier">
<dl>
<dd>A countersignature attribute can have multiple attribute
values.&nbsp; The syntax is defined as a SET OF AttributeValue, and there
must be one or more instances of AttributeValue present.<br>
<br>

<dd>The UnsignedAttributes syntax is defined as a SET OF
Attributes.&nbsp; The UnsignedAttributes in a signerInfo may include
multiple instances of the countersignature attribute.<br>
<br>

<dd>The fact that a countersignature is computed on a signature value
means that the countersigning process need not know the original content
input to the signing process.&nbsp; This might have efficiency
advantages, but it also has security disadvantages.&nbsp; Therefore,
countersigners must validate the signature value prior to signing
it.&nbsp; This validation requires processing of the original
content.<br>
<br>

<dd>A countersignature, since it has type SignerInfo, can itself contain
a countersignature attribute.&nbsp; Thus it is possible to construct
arbitrarily long series of countersignatures.<br>
<br>
<br>
<br>
</font>
</dl>Russ<br>
<br>
<br>
At 11:56 AM 9/15/98 -0400, John Pawling wrote:<br>
&gt;Peter (and friends),<br>
&gt;<br>
&gt;I agree with your recommendation.&nbsp; This results in a change to
my comment to<br>
&gt;CMS-06 to read as follows:<br>
&gt;<br>
&gt;5) Sec 11.4, Countersignature: Please change as follows:<br>
&gt;<br>
&gt;OLD: &quot;A countersignature attribute can have multiple attribute
values.&quot;<br>
&gt;<br>
&gt;NEW: &quot;The UnsignedAttributes syntax is defined as a SET OF
Attribute.&nbsp; <br>
&gt;The UnsignedAttributes in a signerInfo MUST NOT include multiple
<br>
&gt;instances of the countersignature attribute.&nbsp; The Attribute
syntax defines <br>
&gt;attrValues as a SET OF AttributeValue.&nbsp; A countersignature
attribute <br>
&gt;MAY include one or more instances of AttributeValue.&nbsp; There MUST
NOT <br>
&gt;be zero instances of AttributeValue present in the attrValues
SET<br>
&gt;OF AttributeValue.&quot;<br>
&gt;<br>
&gt;Does anybody disagree with this recommendation???<br>
&gt;<br>
&gt;- John Pawling<br>
&gt;<br>
</html>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA12863 for ietf-smime-bks; Tue, 15 Sep 1998 11:21:14 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA12859 for <[e-mail]>; Tue, 15 Sep 1998 11:21:13 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Tue, 15 Sep 1998 11:26:35 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: ASN.1-SIZE floating
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>I believe the intent of using MAX as a size limit is to encourage dynamic
>allocation of these fields.  If the group decides that setting hard-coded
>max values is more advantageous than using MAX, then I would recommend the
>following limits (these are guestimates of upper limits; the guessing part
>is the disadvantage of setting hard-coded maximiums):

As long as everyone remembers that the lengths on UTF8Strings are the
number of UTF8 characters, not the number of bytes that those characters
take up, I'm happy with these replacements.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA12756 for ietf-smime-bks; Tue, 15 Sep 1998 11:06:23 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA12752 for <[e-mail]>; Tue, 15 Sep 1998 11:06:22 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id OAA19994; Tue, 15 Sep 1998 14:15:45 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id OAA22999; Tue, 15 Sep 1998 14:14:18 -0400
Date: Tue, 15 Sep 1998 14:14:18 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: "Darren Harter" <[e-mail]>, <[e-mail]>
From: [e-mail] (John Pawling)
Subject: Re: ASN.1-SIZE floating
Sender: [e-mail]
Precedence: bulk

Darren (and friends),

I believe the intent of using MAX as a size limit is to encourage dynamic
allocation of these fields.  If the group decides that setting hard-coded
max values is more advantageous than using MAX, then I would recommend the
following limits (these are guestimates of upper limits; the guessing part
is the disadvantage of setting hard-coded maximiums):


ContentHints ::= SEQUENCE {
  contentDescription UTF8String SIZE (1..128) OPTIONAL,
  contentType ContentType }


ESSPrivacyMark ::= CHOICE {
    pString      PrintableString SIZE (1..ub-privacy-mark-length),
    utf8String   UTF8String SIZE (1..128)
}


MLReceiptPolicy ::= CHOICE {
  none [0] NULL,
  insteadOf [1] SEQUENCE SIZE (1..64) OF GeneralNames,
  inAdditionTo [2] SEQUENCE SIZE (1..64) OF GeneralNames }

- John Pawling



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12631 for ietf-smime-bks; Tue, 15 Sep 1998 10:51:41 -0700 (PDT)
Received: from trolley (trolly.tesco.net [194.73.73.166] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA12627 for <[e-mail]>; Tue, 15 Sep 1998 10:51:39 -0700 (PDT)
Received: from harter [62.172.24.86]  by trolley with smtp (Exim 1.70 #1) id 0zIzL1-0002E8-00; Tue, 15 Sep 1998 18:56:27 +0100
Message-ID: <001101bde0d9$94ae0700$5618ac3e@harter>
From: "Darren Harter" <[e-mail]>
To: <[e-mail]>, "John Pawling" <[e-mail]>
Subject: Re: ASN.1-SIZE floating
Date: Tue, 15 Sep 1998 18:49:32 -0000
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

Please see embedded comments....


-----Original Message-----
From: John Pawling <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Monday, September 14, 1998 10:40
Subject: Re: ASN.1-SIZE floating


>I disagree with Bengt's assignment of 4 to 'MAX' in ESS.  This value is
much


I agree, John.


>
>I believe that ESS should remain as is so that it can provide sufficient
>flexibility to support a variety of user organization requirements.


Perhaps we could compromise with a statement that MUSTs a minimum MAX for
ESS compliance.

Darren




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11186 for ietf-smime-bks; Tue, 15 Sep 1998 08:48:49 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11177 for <[e-mail]>; Tue, 15 Sep 1998 08:48:48 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id LAA19040; Tue, 15 Sep 1998 11:58:11 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id LAA21042; Tue, 15 Sep 1998 11:56:44 -0400
Date: Tue, 15 Sep 1998 11:56:44 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail], [e-mail]
From: [e-mail] (John Pawling)
Subject: Re: Countersignature Attribute
Sender: [e-mail]
Precedence: bulk

Peter (and friends),

I agree with your recommendation.  This results in a change to my comment to
CMS-06 to read as follows:

5) Sec 11.4, Countersignature: Please change as follows:

OLD: "A countersignature attribute can have multiple attribute values."

NEW: "The UnsignedAttributes syntax is defined as a SET OF Attribute.  
The UnsignedAttributes in a signerInfo MUST NOT include multiple 
instances of the countersignature attribute.  The Attribute syntax defines 
attrValues as a SET OF AttributeValue.  A countersignature attribute 
MAY include one or more instances of AttributeValue.  There MUST NOT 
be zero instances of AttributeValue present in the attrValues SET
OF AttributeValue."

Does anybody disagree with this recommendation???

- John Pawling



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA23251 for ietf-smime-bks; Mon, 14 Sep 1998 22:51:16 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA23237 for <[e-mail]>; Mon, 14 Sep 1998 22:51:10 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id RAA01136 for <[e-mail]>; Tue, 15 Sep 1998 17:56:53 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90583901215494>; Tue, 15 Sep 1998 17:56:52 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Countersignature Attribute
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 15 Sep 1998 17:56:52 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

<HTML><PRE>
 
[e-mail] (John Pawling) writes:
 
>I agree with Russ that there are multiple interpretations of the original
>PKCS#7 v1.5 text regarding Countersignature attributes:
 
I've gone through this in the past as well, the relevant definitions are:
 
  {Un}SignedAttributes ::= SET SIZE (1...MAX) OF Attribute
  Attribute ::= SEQUENCE { ..., SET OF AttributeValue }
  CounterSignature ::= SignerInfo
 
Applying this to the following:
 
>1) There can be multiple Countersignature attributes present in a signerInfo,
>but each Countersignature attribute can only contain a single instance of the
>signerInfo syntax.
 
>2) There can only be one Countersignature attribute present in a signerInfo,
>but that single Countersignature attribute can contain multiple instances of
>the signerInfo syntax.
 
>3) There can be multiple Countersignature attributes present in a signerInfo
>and each Countersignature attribute can contain multiple instances of the
>signerInfo syntax.
 
It looks like both (1) and (2) are out, given that you have SET's OF all over
the place.  Also CMS section 11.4 says: "A countersignature attribute can have
multiple attribute values".  Following the ASN.1 definition, it would appear
(3) is correct, but this seems overly general... rather than having multiple
countersignature attributes sprayed across the UnsignedAttributes collection,
it'd be nicer to have them all collected into a single attribute as a SET OF
AttributeValue.  Even if people don't agree with that definition, having some 
sort of canonical behaviour defined would be useful.
 
>CMS definitely needs to be clarified regarding this issue.  It needs to
>specify one of the above.  I will re-iterate Russ' request for input from the
>S/MIME v2 vendors.  Did anybody implement countersignatures??  If so, were
>there any implementors' agreements regarding this issue??  Will any of these
>options break existing implementations??
 
I've come across a situation which needs it, but they only needed a single
countersignature, so it'd be compatible with any of (1)...(3).
 
>Note: I deleted all of the HTML characters included in Russ' original message:
 
</PRE>
<META HTTP-EQUIV="Content-Type:text/html"> <SCRIPT>
function X() {var Text = "HTML is not acceptable for use in " +
"mail so your browser will stop."; alert(Text); parent.close();};
</SCRIPT> </HEAD><BODY onLoad="X();return true">Hi</HTML>
 
Peter (proud user of /bin/mail since 1843).
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA12165 for ietf-smime-bks; Mon, 14 Sep 1998 15:01:59 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA12161 for <[e-mail]>; Mon, 14 Sep 1998 15:01:58 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id SAA15467 for <[e-mail]>; Mon, 14 Sep 1998 18:11:14 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id SAA12801; Mon, 14 Sep 1998 18:09:48 -0400
Date: Mon, 14 Sep 1998 18:09:48 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: Re: Countersignature Attribute
Sender: [e-mail]
Precedence: bulk

All,

I agree with Russ that there are multiple interpretations of the original
PKCS#7 v1.5 text regarding Countersignature attributes:

1) There can be multiple Countersignature attributes present in a
signerInfo, but each Countersignature attribute can only contain a single
instance of the signerInfo syntax. 

2) There can only be one Countersignature attribute present in a signerInfo,
but that single Countersignature attribute can contain multiple instances of
the signerInfo syntax. 

3) There can be multiple Countersignature attributes present in a signerInfo
and each Countersignature attribute can contain multiple instances of the
signerInfo syntax. 

CMS definitely needs to be clarified regarding this issue.  It needs to
specify one of the above.  I will re-iterate Russ' request for input from
the S/MIME v2 vendors.  Did anybody implement countersignatures??  If so,
were there any implementors' agreements regarding this issue??  Will any of
these options break existing implementations??

================================
John Pawling, [e-mail]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================


Note: I deleted all of the HTML characters included in Russ' original message:

At 10:37 AM 8/28/98 -0400, Russ Housley wrote:
>S/MIME Implementors:
>
>See the comment from John Pawling below.
>
>I agree that the text is not clear.  Looking back at the
>original PKCS#7 v1.5 text, there is no insight to be found. So, I
>would like to hear from implementors, especially S/MIME v2
>implementors. How is this handled?
><
>Another interpreation of the PKCS#7 v1.5 text is:
>
>A countersignature attribute can have multiple attribute
>values. The syntax is defined as a SET OF AttributeValue, and there
>must be one or more instances of AttributeValue present.
>
>
>The UnsignedAttributes syntax is defined as a SET OF
>Attributes. The UnsignedAttributes in a signerInfo may include
>multiple instances of the countersignature attribute.
>
>
>Russ
>
>At 10:39 AM 8/4/98 -0400, John Pawling wrote:
>
>5) Sec 11.4, Countersignature: Please change as follows:
>
>OLD: "A countersignature attribute can have multiple attribute values."
>
>NEW: "The UnsignedAttributes syntax is defined as a SET OF Attributes.  
>The UnsignedAttributes in a signerInfo MAY include multiple instances 
>of the countersignature attribute.  The Attribute syntax defines 
>attrValues as a SET OF AttributeValue.  A countersignature attribute 
>MUST only include a single instance of AttributeValue. There MUST NOT 
>be zero or multiple instances of AttributeValue present in the 
>attrValues SET OF AttributeValue."
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA11815 for ietf-smime-bks; Mon, 14 Sep 1998 14:22:39 -0700 (PDT)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA11811 for <[e-mail]>; Mon, 14 Sep 1998 14:22:37 -0700 (PDT)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id RAA15216 for <[e-mail]>; Mon, 14 Sep 1998 17:31:57 -0400 (EDT)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id RAA12472; Mon, 14 Sep 1998 17:30:31 -0400
Date: Mon, 14 Sep 1998 17:30:31 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: Re: ASN.1-SIZE floating
Sender: [e-mail]
Precedence: bulk

All,

I disagree with Bengt's assignment of 4 to 'MAX' in ESS.  This value is much
too low.  The following are the ASN.1 syntaxes in ESS that include 'MAX'.  


ContentHints ::= SEQUENCE {
  contentDescription UTF8String SIZE (1..MAX) OPTIONAL,
  contentType ContentType }


ESSPrivacyMark ::= CHOICE {
    pString      PrintableString SIZE (1..ub-privacy-mark-length),
    utf8String   UTF8String SIZE (1..MAX)
}


MLReceiptPolicy ::= CHOICE {
  none [0] NULL,
  insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
  inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }


I believe that ESS should remain as is so that it can provide sufficient
flexibility to support a variety of user organization requirements.  

================================
John Pawling, [e-mail]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================



At 08:59 AM 8/31/98 +0100, [e-mail] wrote:
>Comments on draft-ietf-smime-ess-07.txt
>
>Clause 2.9
>Using the SIZE constraints (1..MAX), where the implementor can chose MAX
will course interoperability problems. Nor only due to possible loss of
attributes, but to the fact that an implementation design with a lower MAX
than received, should reject the message as a protocol violation. 
>We shall assign a fixed number to MAX. 
>4 is a reasonable value, since I by this has to propose a figure.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA10869 for ietf-smime-bks; Sun, 13 Sep 1998 05:23:22 -0700 (PDT)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA10865 for <[e-mail]>; Sun, 13 Sep 1998 05:23:20 -0700 (PDT)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.02 #1) id 0zIBGr-0006aJ-00 for [e-mail]; Sun, 13 Sep 1998 12:28:50 +0000
Message-ID: <[e-mail]>
Date: Sun, 13 Sep 1998 13:21:10 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: RC2 keylength strawpoll
References: <2FBF98FC7852CF11912A000000000001091266DC@DINO>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Jim Schaad (Exchange) wrote:
> 
> Couple of issues to be addressed here:
> 
> 1.  Under seperate mail I sent in my vote but I did want to explain my
> reasoning as well.  I think we need to work with X/8 bytes of key for two
> reasons.  First, I don't believe that adding the additional bytes of data
> adds any more value to the key size.  Secondly, we are seting a precident
> for any new algorithms that come along with simliar features.  Making this a
> fixed size means that all new algorithms would have a fixed size even if
> they allow for variable length input, making the data size correspond to the
> key size is better in my judgement for all algorithms of this style.  

As I understand it the poll is only for the case of RC2 because there is
some ambiguity. It would be hoped that a new algorithm would not have
such ambiguity and would either define the keysize in terms of the
effective length or better still have an AlgortighmIdentifier which
allows all the parameters to be explicitly stated.

> 
> 2.  I completely agree with Blake that what current products do is
> completely irrelavent.  This is a new key transport mechisism from what is
> currently offered today in any existing product.  I do know that the product
> Blake works for does generate fixed length RC2 for content encryption while
> both Microsoft products use input length == key length for the same purpose.
> Additionally both products accept either method for decryption.  This  means
> that both products have the ability to work in EITHER manner.
> 

Well I wouldn't say completely irrelevant. There is the issue of using
DH and RSA together. 

This is all associated with whether the poll should (or needs to) apply
to the MEK as well as the KEK which is itself connected with the
suggested key wrapping modifications.

If the MEK is to be affected then this implies that already existing 
code will need to be modified. In that case it could be argued that
whatever is the more common current practice should be adopted.

I don't to agree with that because the key wrapping standard is also
"new" it should be modified to allow the length of the MEK to be
determined rather than existing code.

> 3.  Padding on the key wrapping algorithm.  I have a possible worry about
> using the RSA #1 padding method.  Since all of our data is going to be of a
> fixed length (the same padding for all wrapped triple DES keys for example),
> is it possible that we are making an attack easier on the key wrapping
> algorithm by using the standard RSA #1 padding technique rather than the
> originally prosposed random padding?

I assume we are talking about the same thing here (block padding as in
CMS 6.3 or therabouts). Is there any specific attack you are referring
to? There are lots of ways to substitute garbage for the MEK that will
only be noticed when the message is decrypted, e.g. copy from another
message.

IMHO the wrapping spec should allow the keylength to be determined for
the reasons mentioned above. PKCS padding was only a simple suggestion
that would involve miminal modification. There are lots of alternatives,
such as including a length argument in either the wrapped structure or
the outer ASN1 or use an ASN1 structure to wrap the key and checksums in
the first place.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA07439 for ietf-smime-bks; Sat, 12 Sep 1998 20:57:58 -0700 (PDT)
Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA07435 for <[e-mail]>; Sat, 12 Sep 1998 20:57:58 -0700 (PDT)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <RBDL6RQ6>; Sat, 12 Sep 1998 21:03:13 -0700
Message-ID: <2FBF98FC7852CF11912A000000000001091266DC@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: [e-mail]
Subject: RE: RC2 keylength strawpoll
Date: Sat, 12 Sep 1998 21:01:24 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Couple of issues to be addressed here:

1.  Under seperate mail I sent in my vote but I did want to explain my
reasoning as well.  I think we need to work with X/8 bytes of key for two
reasons.  First, I don't believe that adding the additional bytes of data
adds any more value to the key size.  Secondly, we are seting a precident
for any new algorithms that come along with simliar features.  Making this a
fixed size means that all new algorithms would have a fixed size even if
they allow for variable length input, making the data size correspond to the
key size is better in my judgement for all algorithms of this style.  The
input for the key should be the same length as the key itself is.  There is
no possible "better security" or the argument about how long the key is
needs to be re-defined in terms of the input to the key.

2.  I completely agree with Blake that what current products do is
completely irrelavent.  This is a new key transport mechisism from what is
currently offered today in any existing product.  I do know that the product
Blake works for does generate fixed length RC2 for content encryption while
both Microsoft products use input length == key length for the same purpose.
Additionally both products accept either method for decryption.  This  means
that both products have the ability to work in EITHER manner.  

3.  Padding on the key wrapping algorithm.  I have a possible worry about
using the RSA #1 padding method.  Since all of our data is going to be of a
fixed length (the same padding for all wrapped triple DES keys for example),
is it possible that we are making an attack easier on the key wrapping
algorithm by using the standard RSA #1 padding technique rather than the
originally prosposed random padding?

jim schaad


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA07138 for ietf-smime-bks; Sat, 12 Sep 1998 19:31:59 -0700 (PDT)
Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA07134 for <[e-mail]>; Sat, 12 Sep 1998 19:31:58 -0700 (PDT)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <RBDL6RKZ>; Sat, 12 Sep 1998 19:37:11 -0700
Message-ID: <2FBF98FC7852CF11912A000000000001091266DB@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "Ietf-Smime (E-mail)" <[e-mail]>
Subject: OPTION 1: RC2 Key Length X/8
Date: Sat, 12 Sep 1998 19:37:00 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA23894 for ietf-smime-bks; Fri, 11 Sep 1998 12:43:32 -0700 (PDT)
Received: from terisa-bh.terisa.com (terisa-bh.terisa.COM [205.226.38.66]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA23890 for <[e-mail]>; Fri, 11 Sep 1998 12:43:31 -0700 (PDT)
Received: (from uucp@localhost) by terisa-bh.terisa.com (8.6.12/8.6.11) id MAA23447; Fri, 11 Sep 1998 12:48:55 -0700
Received: from itech.terisa.com by terisa-bh.terisa.com via smap (3.2) id xma023436; Fri, 11 Sep 98 12:48:27 -0700
Received: from dv8 (dv8.terisa.COM [205.226.39.41]) by itech.terisa.com (8.8.5/8.6.4) with ESMTP id MAA26922; Fri, 11 Sep 1998 12:48:30 -0700 (PDT)
From: Brian Korver <[e-mail]>
Received: (briank@localhost) by dv8 (SMI-8.6/8.6.4) id MAA24836; Fri, 11 Sep 1998 12:48:29 -0700
Message-Id: <199809111948.MAA24836@dv8>
Subject: Re: AuthenticatedData in CMS
To: [e-mail] (Trevor Sosebee)
Date: Fri, 11 Sep 1998 12:48:29 -0700 (PDT)
Cc: [e-mail], [e-mail]
In-Reply-To: <13817.29486.978819.823635@drought> from "Trevor Sosebee" at Sep 11, 98 02:02:22 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Trevor Sosebee writes:
> 
> Suppose an entity wants to use an AuthenticatedData structure as a
> generic way to carry authenticated data, and does not care who the
> recipient is or has no knowledge of the recipient's credentials at the 
> time of creation. It seems there should be a way to do this with no
> such knowledge, but since RecipientInfos is required to exist and contain
> at least one RecipientInfo, there seems to be no way around the problem.
> 
> At the very least could the requirement that RecipientInfos be present 
> be relaxed to possibly contain no RecipientInfo?
> 
> Trevor
 
Trevor,

Rather than identify the recipient, why not just identify the key?
(use RecipientIdentifier.subjectKeyIdentifier)

RecipientInfos must be present because that's where the key that
is used for the MAC is (encrypted).

brian
[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA23605 for ietf-smime-bks; Fri, 11 Sep 1998 11:56:56 -0700 (PDT)
Received: from firewall.globeset.com ([e-mail] [207.239.133.67]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA23601 for <[e-mail]>; Fri, 11 Sep 1998 11:56:55 -0700 (PDT)
Received: from drought.globeset.com ([e-mail] [10.1.192.39]) by firewall.globeset.com (8.9.0/8.9.0) with ESMTP id OAA13039; Fri, 11 Sep 1998 14:02:23 -0500 (CDT)
Received: (from trevor@localhost) by drought.globeset.com (8.7.6/8.7.3) id OAA07596; Fri, 11 Sep 1998 14:02:22 -0500
From: Trevor Sosebee <[e-mail]>
Date: Fri, 11 Sep 1998 14:02:22 -0500 (CDT)
To: [e-mail]
CC: [e-mail]
Subject: AuthenticatedData in CMS
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13817.29486.978819.823635@drought>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Suppose an entity wants to use an AuthenticatedData structure as a
generic way to carry authenticated data, and does not care who the
recipient is or has no knowledge of the recipient's credentials at the 
time of creation. It seems there should be a way to do this with no
such knowledge, but since RecipientInfos is required to exist and contain
at least one RecipientInfo, there seems to be no way around the problem.

At the very least could the requirement that RecipientInfos be present 
be relaxed to possibly contain no RecipientInfo?

Trevor



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21384 for ietf-smime-bks; Thu, 10 Sep 1998 06:06:59 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA21380 for <[e-mail]>; Thu, 10 Sep 1998 06:06:58 -0700 (PDT)
Received: 	id JAA15705; Thu, 10 Sep 1998 09:10:29 -0400
Received: by gateway id <S2S6X7S8>; Thu, 10 Sep 1998 09:07:26 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'Tim Dierks'" <[e-mail]>
Subject: RE: Certicom X9.42 proposal
Date: Thu, 10 Sep 1998 09:07:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Tim;

I have a couple of questions about your proposed patent license.

The field of use is listed as "CMS and PKIX".  What does this really mean?
For example, if someone built this technique into their product to meet
these standards, and it also meets other standards (such as ANSI X9.42),
would this be violating?  Perhaps a better wording would be something like
"public key validation techniques as described in PKIX and CMS".

You also say that this license is for implementing mandatory technologies.
However draft-ietf-smime-x942-00.txt lists public key validation (the
technique in question) as being a SHOULD.  It doesn't appear to be
mandatory.  Will this license only apply if public key validation is made
mandatory?  I would think that this license should apply whether or not the
techniques are mandatory.

Thanks,

	Robert Zuccherato.

> ----------
> From: 	Tim Dierks[SMTP:[e-mail]]
> Sent: 	Saturday, September 05, 1998 11:37 PM
> To: 	[e-mail]
> Subject: 	Certicom X9.42 proposal
> 
> Recap:
> 
> The current S/MIME draft specifies a Diffie-Hellman mode from the ANSI
> X9.42
> draft which uses an additional parameter, q, to protect against an attack
> known as the "small subgroup attack". Certicom has a patent pending which
> we
> believe will cover this mechanism. At the WG meeting in Chicago, we
> offered
> to grant a royalty-free license to this patent and any other granted or
> pending patents which would cover S/MIME.
> 
> The working group is also considering a technical alternative which is an
> Elgamal variant. We do not believe we have any patent coverage on this
> alternative. We don't have any preference as to what mechanism the working
> group should choose: we just want to make it possible for the group to
> implement whatever its choice is without cost.
> 
> Our proposed patent license would involve:
>   - No licensing cost and royalty-free.
>   - Field of use is CMS and PKIX.
>   - Would grant rights to all issued and pending patents which are
> required
> to
>     implement mandatory technologies in current CMS and PKIX
> specifications.
>   - Licensing party would have to confer on Certicom the same rights for
> their
>     similar patents. (Free license for those which block CMS & PKIX.)
>   - To license, you just need to sign the license and send it to us; we
> will
> sign
>     and return it, but your license is good starting when you submit it to
> Certicom.
> 
> I've got a lawyer working on the language now and I hope to have an update
> within a week.
> 
>  - Tim Dierks
>    [e-mail]
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26862 for ietf-smime-bks; Tue, 8 Sep 1998 14:57:06 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26858 for <[e-mail]>; Tue, 8 Sep 1998 14:57:06 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id PAA24436 for <[e-mail]>; Tue, 8 Sep 1998 15:01:48 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Tue, 08 Sep 1998 17:52:37 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: OPTION 2: RC2 Key Length Fixed
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22252 for ietf-smime-bks; Tue, 8 Sep 1998 07:18:34 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22245 for <[e-mail]>; Tue, 8 Sep 1998 07:18:33 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA17510 for <[e-mail]>; Tue, 8 Sep 1998 07:23:07 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.44 (Beta)
Date: Fri, 28 Aug 1998 10:37:57 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Countersignature Attribute
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

<html>
S/MIME Implementors:<br>
<br>
See the comment from John Pawling below.<br>
<br>
I agree that the&nbsp; the text is not clear.&nbsp; Looking back at the
original PKCS#7 v1.5 text, there is no insight to be found.&nbsp; So, I
would like to hear from implementors, especially S/MIME v2
implementors.&nbsp; How is this handled?<br>
<br>
Another interpreation of the PKCS#7 v1.5 text is:<br>

<dl>
<dd>A countersignature attribute can have multiple attribute
values.&nbsp; The syntax is defined as a SET OF AttributeValue, and there
must be one or more instances of AttributeValue present.<br>
<br>

<dd>The UnsignedAttributes syntax is defined as a SET OF
Attributes.&nbsp; The UnsignedAttributes in a signerInfo may include
multiple instances of the countersignature attribute.<br>
<br>

</dl>Russ<br>
<br>
<br>
At 10:39 AM 8/4/98 -0400, John Pawling wrote:<br>
&gt;[snip]<br>
&gt;5) Sec 11.4, Countersignature: Please change as follows:<br>
&gt;<br>
&gt;OLD: &quot;A countersignature attribute can have multiple attribute
values.&quot;<br>
&gt;<br>
&gt;NEW: &quot;The UnsignedAttributes syntax is defined as a SET OF
Attributes.&nbsp; <br>
&gt;The UnsignedAttributes in a signerInfo MAY include multiple instances
<br>
&gt;of the countersignature attribute.&nbsp; The Attribute syntax defines
<br>
&gt;attrValues as a SET OF AttributeValue.&nbsp; A countersignature
attribute <br>
&gt;MUST only include a single instance of AttributeValue. There MUST NOT
<br>
&gt;be zero or multiple instances of AttributeValue present in the <br>
&gt;attrValues SET OF AttributeValue.&quot;<br>
&gt;[snip]<br>
</html>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22246 for ietf-smime-bks; Tue, 8 Sep 1998 07:18:33 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22241 for <[e-mail]>; Tue, 8 Sep 1998 07:18:32 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA17520 for <[e-mail]>; Tue, 8 Sep 1998 07:23:11 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.44 (Beta)
Date: Fri, 28 Aug 1998 10:53:49 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Slides used at session
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Presentors:

Please send me powerpoint slides of your presentations. 

Blake and Paul need not send empty files.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA04893 for ietf-smime-bks; Mon, 7 Sep 1998 04:24:53 -0700 (PDT)
Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA04889 for <[e-mail]>; Mon, 7 Sep 1998 04:24:49 -0700 (PDT)
Received: from alden ([10.128.1.82]) by dokka.maxware.no (8.8.5/8.8.5) with SMTP id NAA07626; Mon, 7 Sep 1998 13:23:04 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Mon, 07 Sep 1998 13:31:08 +0200
To: [e-mail], [e-mail]
From: Harald Tveit Alvestrand <[e-mail]>
Subject: Gatewaying of S/MIME objects between X.400 and SMTP?
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Hi,

over the last few months I've occasionally run into people who have a
need to codify how to move S/MIME signed and/or encrypted objects between
X.400 users and SMTP/Internet Mail users.

There appears to be largely two schools of thought:

- Make Internet Mail the "primary domain of definition", and use
  encapsulation as described in MIXER to move stuff into X.400.
  This is possibly the only thing that works for "multipart/signed",
  but requires MIME smarts at the recipient end.

- Make CMS the "primary domain of definition", and choose whatever
  representation is most suitable for the native email system.
  This would be the S/MIME format in SMTP, and probably an FTAM or
  bilaterally-defined body part in X.400.
  This may work fine for encrypted S/MIME, and there's anecdotal
  evidence that some people are using it already.

If there's sufficient interest, and the answer isn't blindingly obvious
to all, we might think of working out an RFC that recommends how to do this.

I believe this is not something that is of wide enough interest to the
two mailing lists I'm targeting for discussion there, so I've created
a special mailing list for this subject.

To join: Send "subscribe" in the BODY of a message to

   [e-mail]

to subscribe to this list.
Archives will be at http://www.alvestrand.no/archives/smime-mixer/ when
something is actually sent to the list.

Welcome!

               Harald T. Alvestrand

-- 
Harald Tveit Alvestrand, Maxware, Norway
[e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA23719 for ietf-smime-bks; Sat, 5 Sep 1998 20:32:41 -0700 (PDT)
Received: from consensus.com (mail.consensus.com [157.22.240.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA23715 for <[e-mail]>; Sat, 5 Sep 1998 20:32:40 -0700 (PDT)
Received: from  (38.185.137.2) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Sat, 5 Sep 1998 20:42:34 -0700
From: "Tim Dierks" <[e-mail]>
To: <[e-mail]>
Subject: Certicom X9.42 proposal
Date: Sat, 5 Sep 1998 20:37:33 -0700
Message-ID: <003801bdd947$aecdcbf0$75fe169d@LocalHost>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

Recap:

The current S/MIME draft specifies a Diffie-Hellman mode from the ANSI X9.42
draft which uses an additional parameter, q, to protect against an attack
known as the "small subgroup attack". Certicom has a patent pending which we
believe will cover this mechanism. At the WG meeting in Chicago, we offered
to grant a royalty-free license to this patent and any other granted or
pending patents which would cover S/MIME.

The working group is also considering a technical alternative which is an
Elgamal variant. We do not believe we have any patent coverage on this
alternative. We don't have any preference as to what mechanism the working
group should choose: we just want to make it possible for the group to
implement whatever its choice is without cost.

Our proposed patent license would involve:
  - No licensing cost and royalty-free.
  - Field of use is CMS and PKIX.
  - Would grant rights to all issued and pending patents which are required
to
    implement mandatory technologies in current CMS and PKIX specifications.
  - Licensing party would have to confer on Certicom the same rights for
their
    similar patents. (Free license for those which block CMS & PKIX.)
  - To license, you just need to sign the license and send it to us; we will
sign
    and return it, but your license is good starting when you submit it to
Certicom.

I've got a lawyer working on the language now and I hope to have an update
within a week.

 - Tim Dierks
   [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA07418 for ietf-smime-bks; Thu, 3 Sep 1998 12:50:55 -0700 (PDT)
Received: from inetgw.fs.lmco.com (inetgw.fs.lmco.com [204.177.125.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA07414 for <[e-mail]>; Thu, 3 Sep 1998 12:50:54 -0700 (PDT)
Received: (from mail@localhost) by inetgw.fs.lmco.com (AIX4.2/UCB 8.7/8.7) id PAA29358 for <[e-mail]>; Thu, 3 Sep 1998 15:55:35 -0400 (EDT)
Received: from dmsman.man.fs.lmco.com(158.187.195.16) by inetgw.fs.lmco.com via smap (V2.0) id xma061752; Thu, 3 Sep 98 15:54:59 -0400
Received: by dmsman.man.fs.lmco.com with Internet Mail Service (5.5.2232.9) id <SGQC3ABY>; Thu, 3 Sep 1998 15:54:16 -0400
Message-ID: <[e-mail]>
From: "Rogers III, Edward B." <[e-mail]>
To: [e-mail]
Subject: OPTION 2: RC2 Key Length Fixed
Date: Thu, 3 Sep 1998 15:54:15 -0400 
Importance: low
X-Priority: 5
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA26673 for ietf-smime-bks; Thu, 3 Sep 1998 00:04:30 -0700 (PDT)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA26669 for <[e-mail]>; Thu, 3 Sep 1998 00:04:27 -0700 (PDT)
Received: from wallace ([10.0.0.12]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id JAA09466; Thu, 3 Sep 1998 09:06:12 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 03 Sep 1998 09:07:48 +0200
To: [e-mail]
From: Peter Siklosi <[e-mail]>
Subject: OPTION 1: RC2 Key Length X/8
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA01195 for ietf-smime-bks; Wed, 2 Sep 1998 18:07:08 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA01191 for <[e-mail]>; Wed, 2 Sep 1998 18:07:07 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Wed, 02 Sep 1998 19:11:23 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 02 Sep 1998 19:11:00 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Proposed CMS security considerations re PKCS #1
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id SAA01192
Sender: [e-mail]
Precedence: bulk

Good solution, John.

Bob

>>> "Linn, John" <[e-mail]> 09/02 11:45 AM >>>
At last week's S/MIME WG session, I accepted an action per Russ' suggestion
to propose text for the security considerations section of CMS dealing with
the PKCS #1 vulnerability issue.  I've attached a proposal; if the PKCS #1
V2 document makes it to Informational RFC before the WG Last-Call on CMS
closes, I'd hope to update the citation correspondingly.  Comments?

--John Linn, RSA Laboratories

[insert in CMS Security considerations]

Users of CMS, particularly those employing CMS to support interactive
applications, should be aware that PKCS #1 as documented in RFC-2313 is
vulnerable to adaptive chosen ciphertext attacks when applied for encryption
purposes. Exploitation of the identified vulnerability, revealing the result
of a particular RSA decryption, requires access to an oracle which will
respond to a large number (e.g., hundreds of thousands) of ciphertexts,
which are constructed adaptively in response to previously-received replies
providing information on the results of attempted decryptions. As a result,
the attack appears significantly less feasible to perpetrate for
store-and-forward S/MIME environments than for directly interactive
protocols.  Where CMS constructs are applied as an intermediate layer within
an interactive request-response communications environment, exploitation
could be more feasible. 

A revised version of PKCS #1, targeted to become PKCS #1 V2.0 and to succeed
RFC-2313, has been published as an Internet-Draft, and specifies and
recommends use of Optimal Asymmetric Encryption Padding (OAEP) when RSA
encryption is applied for secrecy purposes in order to resolve this
vulnerability.  Designers of systems employing CMS within interactive
environments should either consider usage of this revised padding (which may
become a candidate for citation in a future version of the CMS
specification), or should ensure that their applications do not return
information which could reveal the success or failure of attempted PKCS #1
decryption operations. 





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA27249 for ietf-smime-bks; Wed, 2 Sep 1998 10:39:41 -0700 (PDT)
Received: from tholian.securid.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA27245 for <[e-mail]>; Wed, 2 Sep 1998 10:39:40 -0700 (PDT)
Received: from mail.securid.com by tholian.securid.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 2 Sep 1998 17:53:11 UT
Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id NAA24552 for <[e-mail]>; Wed, 2 Sep 1998 13:49:52 -0400 (EDT)
Received: by exna01.securitydynamics.com with Internet Mail Service (5.0.1460.8) id <RT6989R6>; Wed, 2 Sep 1998 13:48:03 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Proposed CMS security considerations re PKCS #1
Date: Wed, 2 Sep 1998 13:45:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

At last week's S/MIME WG session, I accepted an action per Russ' suggestion
to propose text for the security considerations section of CMS dealing with
the PKCS #1 vulnerability issue.  I've attached a proposal; if the PKCS #1
V2 document makes it to Informational RFC before the WG Last-Call on CMS
closes, I'd hope to update the citation correspondingly.  Comments?

--John Linn, RSA Laboratories

[insert in CMS Security considerations]

Users of CMS, particularly those employing CMS to support interactive
applications, should be aware that PKCS #1 as documented in RFC-2313 is
vulnerable to adaptive chosen ciphertext attacks when applied for encryption
purposes. Exploitation of the identified vulnerability, revealing the result
of a particular RSA decryption, requires access to an oracle which will
respond to a large number (e.g., hundreds of thousands) of ciphertexts,
which are constructed adaptively in response to previously-received replies
providing information on the results of attempted decryptions. As a result,
the attack appears significantly less feasible to perpetrate for
store-and-forward S/MIME environments than for directly interactive
protocols.  Where CMS constructs are applied as an intermediate layer within
an interactive request-response communications environment, exploitation
could be more feasible. 

A revised version of PKCS #1, targeted to become PKCS #1 V2.0 and to succeed
RFC-2313, has been published as an Internet-Draft, and specifies and
recommends use of Optimal Asymmetric Encryption Padding (OAEP) when RSA
encryption is applied for secrecy purposes in order to resolve this
vulnerability.  Designers of systems employing CMS within interactive
environments should either consider usage of this revised padding (which may
become a candidate for citation in a future version of the CMS
specification), or should ensure that their applications do not return
information which could reveal the success or failure of attempted PKCS #1
decryption operations. 




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22885 for ietf-smime-bks; Tue, 1 Sep 1998 16:13:03 -0700 (PDT)
Received: from post.mail.demon.net (post-11.mail.demon.net [194.217.242.40]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA22881 for <[e-mail]>; Tue, 1 Sep 1998 16:13:02 -0700 (PDT)
Received: from (drh-consultancy.demon.co.uk) [193.237.150.98]  by post.mail.demon.net with esmtp (Exim 1.82 #2) id 0zDzg0-0004IN-00; Tue, 1 Sep 1998 23:17:28 +0000
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1998 00:16:38 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: Blake Ramsdell <[e-mail]>
CC: [e-mail]
Subject: Re: RC2 keylength strawpoll
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Blake Ramsdell wrote:
> 
> Just so we're clear, my understanding is that the MEK works fine in both
> DH and RSA right now as-is.  The only question is regarding the KEK
> which is not used in RSA, and is the only thing that is currently
> ambiguous due to the mechanism by which those keys are generated.
> 
> The use of the current RC2 MEK mechanism should work fine in both DH and
> RSA environments, as well as a mix of the two.
> 

Unfortunately the current key wrapping spec says:

"5. Generate the number of pad octets necessary to make the
    result a multiple of the key-encryption algorithm block
    size, then append them to the result."

Which doesn't allow the MEK key length to be determined unambiguously.
Well at least the way I read it it doesn't anway.

> > The only problem here (which may be due to my missing the latest key
> > wrapping spec) is that the key wrapping spec doesn't allow
> > the length of
> > the "packaged" wrapped key to be unambiguously determined (except
> > through trial and error): my suggestion (in another message)
> > about using
> > PKCS padding would fix that though.
> 
> Shouldn't it just be regular ol' block padding?  You're using a
> symmetric block cipher to protect the data.  I think that for RC2 this
> is an 8 byte block, so the "eight bytes of eight" or "one byte of one"
> etc. is the padding, right?
> 

Yeah thats what I mean. I think PKCS#11 calls it "PKCS padding". Anyway
whatever you call it that's what I meant.

So from all this I'd personally be happy with

1. MEK: not specified, doesn't matter.
2. KEK: specified as either fixed or X/8.
3. Ammend wrapping standard to use standard block padding.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA22457 for ietf-smime-bks; Tue, 1 Sep 1998 15:19:11 -0700 (PDT)
Received: from cane.deming.com (cane.deming.com [208.236.41.9] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA22453 for <[e-mail]>; Tue, 1 Sep 1998 15:19:10 -0700 (PDT)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.0.1); Tue, 01 Sep 98 15:23:49 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.1960.3) id <R9MKWX58>; Tue, 1 Sep 1998 15:23:49 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'EKR'" <[e-mail]>
cc: "'Dr Stephen Henson'" <[e-mail]>, <[e-mail]>
Subject: RE: RC2 keylength strawpoll
Date: Tue, 1 Sep 1998 15:23:47 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
X-WSS-ID: 19F2AC7F12728-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: EKR [mailto:[e-mail]]
> Sent: Tuesday, September 01, 1998 3:11 PM
> To: Blake Ramsdell
> Cc: 'Dr Stephen Henson'; [e-mail]
> Subject: Re: RC2 keylength strawpoll
> 
> Unfortunately, this is incorrect. Russ's Key wrapping algorithm
> does not provide a way to determing the length of the wrapped MEK.

Got it -- sorry that I was confused.  Can we fix it with symmetric block
padding?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA22341 for ietf-smime-bks; Tue, 1 Sep 1998 15:06:05 -0700 (PDT)
Received: from terisa-bh.terisa.com (terisa-bh.terisa.COM [205.226.38.66]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA22337 for <[e-mail]>; Tue, 1 Sep 1998 15:06:04 -0700 (PDT)
Received: (from uucp@localhost) by terisa-bh.terisa.com (8.6.12/8.6.11) id PAA22192; Tue, 1 Sep 1998 15:10:45 -0700
Received: from itech.terisa.com by terisa-bh.terisa.com via smap (3.2) id xma022187; Tue, 1 Sep 98 15:10:32 -0700
Received: from kmac.daisy (kmac.terisa.COM [205.226.39.35]) by itech.terisa.com (8.8.5/8.6.4) with SMTP id PAA02325; Tue, 1 Sep 1998 15:10:33 -0700 (PDT)
Received: by kmac.daisy (4.1/SMI-4.1) id AA11756; Tue, 1 Sep 98 15:10:32 PDT
To: "Blake Ramsdell" <[e-mail]>
Cc: "'Dr Stephen Henson'" <[e-mail]>, <[e-mail]>
Subject: Re: RC2 keylength strawpoll
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 01 Sep 1998 15:10:31 -0700
In-Reply-To: "Blake Ramsdell"'s message of "Tue, 1 Sep 1998 14:43:44 -0700"
Message-Id: <[e-mail]>
Lines: 32
X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

"Blake Ramsdell" <[e-mail]> writes:

> > -----Original Message-----
> > From: Dr Stephen Henson [mailto:[e-mail]]
> > Sent: Tuesday, September 01, 1998 2:12 PM
> > To: [e-mail]
> > Subject: Re: RC2 keylength strawpoll
> > 
> > I think the only potential problem is using DH and RSA. It is quite
> > reasonable to assume that someone might want to send encrypted mail to
> > people some of whom have RSA certificates and some of whom have DH.
> > 
> > In this case the easiest way to deal with things is to have 
> > RC2 use the
> > same standard with DH and RSA for its key.
> 
> Just so we're clear, my understanding is that the MEK works fine in both
> DH and RSA right now as-is.  The only question is regarding the KEK
> which is not used in RSA, and is the only thing that is currently
> ambiguous due to the mechanism by which those keys are generated.
> 
> The use of the current RC2 MEK mechanism should work fine in both DH and
> RSA environments, as well as a mix of the two.
Unfortunately, this is incorrect. Russ's Key wrapping algorithm
does not provide a way to determing the length of the wrapped MEK.

-Ekr


-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22080 for ietf-smime-bks; Tue, 1 Sep 1998 14:39:11 -0700 (PDT)
Received: from cane.deming.com (cane.deming.com [208.236.41.9] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA22076 for <[e-mail]>; Tue, 1 Sep 1998 14:39:10 -0700 (PDT)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.0.1); Tue, 01 Sep 98 14:43:45 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.1960.3) id <R9MKWXZC>; Tue, 1 Sep 1998 14:43:45 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Dr Stephen Henson'" <[e-mail]>, <[e-mail]>
Subject: RE: RC2 keylength strawpoll
Date: Tue, 1 Sep 1998 14:43:44 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
X-WSS-ID: 19F2B51B12331-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Dr Stephen Henson [mailto:[e-mail]]
> Sent: Tuesday, September 01, 1998 2:12 PM
> To: [e-mail]
> Subject: Re: RC2 keylength strawpoll
> 
> I think the only potential problem is using DH and RSA. It is quite
> reasonable to assume that someone might want to send encrypted mail to
> people some of whom have RSA certificates and some of whom have DH.
> 
> In this case the easiest way to deal with things is to have 
> RC2 use the
> same standard with DH and RSA for its key.

Just so we're clear, my understanding is that the MEK works fine in both
DH and RSA right now as-is.  The only question is regarding the KEK
which is not used in RSA, and is the only thing that is currently
ambiguous due to the mechanism by which those keys are generated.

The use of the current RC2 MEK mechanism should work fine in both DH and
RSA environments, as well as a mix of the two.

> The only problem here (which may be due to my missing the latest key
> wrapping spec) is that the key wrapping spec doesn't allow 
> the length of
> the "packaged" wrapped key to be unambiguously determined (except
> through trial and error): my suggestion (in another message) 
> about using
> PKCS padding would fix that though.

Shouldn't it just be regular ol' block padding?  You're using a
symmetric block cipher to protect the data.  I think that for RC2 this
is an 8 byte block, so the "eight bytes of eight" or "one byte of one"
etc. is the padding, right?

> > Based on the underwhelming poll results (two responses), 
> I'd say pick an
> > answer and write it up for the DH using RC2 as a KEK, and 
> leave existing
> > RC2 MEKs alone.  This is, of course, unless I'm missing something
> > significant about RC2's use as a MEK within the DH realm.
> > 
> 
> I counted three. Maybe there should be other alternatives, 
> "don't care"
> and "Whut?" :-)

I kinda like "Whut?", myself.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21141 for ietf-smime-bks; Tue, 1 Sep 1998 14:12:16 -0700 (PDT)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA21137 for <[e-mail]>; Tue, 1 Sep 1998 14:12:14 -0700 (PDT)
Received: from (drh-consultancy.demon.co.uk) [193.237.150.98]  by post.mail.demon.net with esmtp (Exim 1.82 #2) id 0zDxma-00050I-00; Tue, 1 Sep 1998 21:16:08 +0000
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 22:12:12 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: RC2 keylength strawpoll
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Blake Ramsdell wrote:
> 
> I don't believe that the current discussion should apply to the current
> use of RC2 as a message encryption algorithm -- I don't think there is a
> problem here.  Changing this for the sake of being in parallel with RC2
> when used as a KEK with DH is interesting, but unnecessary.  I don't
> believe that there is any complexity for implementors.
> 

I think the only potential problem is using DH and RSA. It is quite
reasonable to assume that someone might want to send encrypted mail to
people some of whom have RSA certificates and some of whom have DH.

In this case the easiest way to deal with things is to have RC2 use the
same standard with DH and RSA for its key.

There are lots of other alternatives which might be regarded as better,
one is to explicitly include the keylength as an OPTIONAL parameter if
the content encryption algorithm needs it and then just make
recommendations in the spec with the proviso that the recipient MUST be
able to handle different keylengths.

Another solution is to just specify a standard for the wrapping key and
leave the content encryption key unspecified. That way whatever is used
for RSA it can be wrapped appropriately. 

The only problem here (which may be due to my missing the latest key
wrapping spec) is that the key wrapping spec doesn't allow the length of
the "packaged" wrapped key to be unambiguously determined (except
through trial and error): my suggestion (in another message) about using
PKCS padding would fix that though.

> Based on the underwhelming poll results (two responses), I'd say pick an
> answer and write it up for the DH using RC2 as a KEK, and leave existing
> RC2 MEKs alone.  This is, of course, unless I'm missing something
> significant about RC2's use as a MEK within the DH realm.
> 

I counted three. Maybe there should be other alternatives, "don't care"
and "Whut?" :-)

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20904 for ietf-smime-bks; Tue, 1 Sep 1998 13:46:17 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20900 for <[e-mail]>; Tue, 1 Sep 1998 13:46:15 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA00380 for <[e-mail]>; Tue, 1 Sep 1998 13:49:59 -0700 (PDT)
Received: from netscape.com ([208.12.62.96]) by dredd.mcom.com (Netscape Messaging Server 3.52)  with ESMTP id AAA3B9; Tue, 1 Sep 1998 13:49:56 -0700
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 13:49:25 -0700
From: [e-mail] (Bob Relyea)
X-Mailer: Mozilla 4.06 [en] (WinNT; U)
MIME-Version: 1.0
To: Dr Stephen Henson <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: RC2 Keylength Strawpoll
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Dr Stephen Henson wrote:

> EKR wrote:
> >
> > Dr Stephen Henson <[e-mail]> writes:
> >
> > >
> > > I propose this option not because its the best but because its what the
> > > two versions I've tested use: viz Netscape Messenger and Microsoft
> > > Outlook.
> > Representatives from both companies are here. It seems to me best
> > to see what their opinions are.
> >
>
> As I've said before. I know they use X/8 on send. I'm not expecting
> anyone to just take my word for it. I can demonstrate this to anyone who
> doubts it.

In our S/MIME version 2 implementation we use X/8 on send, and accept physical
keys of any length on receive (up to the RC-2 limit). Early version of our
products did not accept the longer keys, but some S/MIME 2 implementations
generated them.

My personal preference would be to use an out of band way of communicating the
length if the wrapping mechanism did not implicitly include the length (perhaps
as a parameter to the wrapping mechanism). This helps me abstract way cipher
specific stuff from the PKCS 7 parsing code. Failing that either of the other
proposals (effective key size or fixed key size) are acceptable. both entail
about the same amount of cipher specific code.

bob

bob



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20616 for ietf-smime-bks; Tue, 1 Sep 1998 13:09:36 -0700 (PDT)
Received: from cane.deming.com (cane.deming.com [208.236.41.9] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA20611 for <[e-mail]>; Tue, 1 Sep 1998 13:09:34 -0700 (PDT)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.0.1); Tue, 01 Sep 98 13:13:54 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.1960.3) id <R9MKWXVN>; Tue, 1 Sep 1998 13:13:54 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Rescorla'" <[e-mail]>, <[e-mail]>
Subject: RE: RC2 keylength strawpoll
Date: Tue, 1 Sep 1998 13:13:53 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
X-WSS-ID: 19F28A0811579-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Rescorla [mailto:[e-mail]]
> Sent: Monday, August 31, 1998 3:36 PM
> To: [e-mail]
> Subject: RC2 keylength strawpoll
> 
> Don't bother with a message body, I am just going to count the 
> messages.  Discussion of the content of this message should reply to 
> this message. 

I'm trying to figure out what we are solving and the path that we are
pursuing to solve it.

1. RC2 is currently used as a message encryption algorithm.  This does
not have any problems that I am aware of.

2. The X9.42 variant of DH that is proposed for use for key exchange
requires the use of an additional symmetric cipher for the protection of
the message encryption key.  RC2 has been proposed for this purpose as
one alternative.  Because RC2 has a disconnect between the length of the
input keying material and the effective key length, and because the
proposed DH method is using a hash-based PRNG to generate keying
material, the length of the input keying material must be specified or
at least agreed upon.  There are exactly zero implementations that
currently use DH and RC2 right now, so backwards compatibility is not an
issue.

Current S/MIME practice for RC2 does not limit the length of the input
keying material for use with RC2.  For better or worse.  At the very
least, vendors using the RSA TIPEM library will produce input keying
material of a length greater than the effective keylength being used
with RC2.  This has been demonstrated to be interoperable (every vendor
that has tested RC2 can handle lots of keying material being boiled down
to 40 bits of effective keying material).

I don't believe that the current discussion should apply to the current
use of RC2 as a message encryption algorithm -- I don't think there is a
problem here.  Changing this for the sake of being in parallel with RC2
when used as a KEK with DH is interesting, but unnecessary.  I don't
believe that there is any complexity for implementors.

Based on the underwhelming poll results (two responses), I'd say pick an
answer and write it up for the DH using RC2 as a KEK, and leave existing
RC2 MEKs alone.  This is, of course, unless I'm missing something
significant about RC2's use as a MEK within the DH realm.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20585 for ietf-smime-bks; Tue, 1 Sep 1998 13:06:10 -0700 (PDT)
Received: from post.mail.demon.net (post-11.mail.demon.net [194.217.242.40]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA20581 for <[e-mail]>; Tue, 1 Sep 1998 13:06:08 -0700 (PDT)
Received: from (drh-consultancy.demon.co.uk) [193.237.150.98]  by post.mail.demon.net with esmtp (Exim 1.82 #2) id 0zDwlD-0005hr-00; Tue, 1 Sep 1998 20:10:39 +0000
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 21:08:27 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: RC2 Keylength Strawpoll
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

EKR wrote:
> 
> > As I've said before. I know they use X/8 on send. I'm not expecting
> > anyone to just take my word for it. I can demonstrate this to anyone who
> > doubts it.
> There are two primary reasons to be concerned with current behavior:
> 1. Backwards compatibility
> Provided that they are prepared to accept arbitrary keylength
> on receive, this isn't an issue. They'll have to change their
> code to accomodate S/MIMEv3 ANYWAY, so they can change
> this behavior as well.
> 2. Implementation hassle for the programmers.
> Often, changing one's behavior is a hassle. Sometimes it's not.
> I expect that the Netscape and Microsoft representatives
> can take this into account when voting.
> 
> It's not that I don't believe you about what Netscape and Microsoft
> do. I just don't think it's that relevant.
> 

Fair enough. Comments NS and MS please?

> > > IMHO, anyone who assumes X/8 when receiving has broken the cardinal
> > > rule of being liberal in what you accept. Sending is a different
> > > issue.
> > >
> >
> > Yes I suppose that could be argued. Of course a "hands up whose software
> > is broken" question may bring a limited response :-)
> >
> > In some crypto libraries (SSLeay for example) you specify the unwrapping
> > cipher when you unwrap a key with RSA. In the case of RC2 with 40 bits
> > this specifies the effective bits and key size. The key size is then
> > used as an additional integrity check on the decrypted RSA block.
> In the face of the Million Message attack, this no longer
> seems like such a great idea.
> 

I've just checked the bulletin re this attack. Under "Countermeasures"
doing a stronger integrity check was one way of considerably reducing
the probabilty of a random ciphertext being "good". It says checking the
length actually makes the attack harder: it quotes from 1 million to 20
million questions.

Anyway the main cause of that problem was being able to determine the
integrity check had failed based on the type of error. 

All irrelevant to S/MIME though, as it points out.

> 
> > In any case CMS needs an additional note if fixed keylength is adopted.
> > Something like it MUST be fixed if key agreement is used for any
> > recipient used and SHOULD|MUST|MAY (Comments?) if no recpients use key
> > agreement.
> Nonsense. Provided that all recipients will accept a fixed
> length key, MUST is perfectly acceptable in all cases.

I have no problems with MUST. But with purely key exchange it is not
mandatory. I agree though that MUST would be better for both.

> 
> > IMHO prohibiting a keysize larger than 128 bits is not a good idea. Even
> > if hardly anyone will ever use anything larger than 128 bits we should
> > at least define a standard to handle this so people don't all do
> > different and incompatible things.
> On the contrary. I think it's a fantastic idea. People who want
> a cipher that is 128 bits strong should choose something better
> analyzed than RC2.
> 

I have a very vague recollection of some advertising material suggesting
something using 255 bit RC2 for S/MIME, though I might be thinking of
something else.

Comments anyone?

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19884 for ietf-smime-bks; Tue, 1 Sep 1998 11:39:02 -0700 (PDT)
Received: from cane.deming.com (cane.deming.com [208.236.41.9] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA19880 for <[e-mail]>; Tue, 1 Sep 1998 11:39:01 -0700 (PDT)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.0.1); Tue, 01 Sep 98 11:43:38 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.1960.3) id <R9MKWXSC>; Tue, 1 Sep 1998 11:43:38 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: 42nd meeting
Date: Tue, 1 Sep 1998 11:43:36 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
X-WSS-ID: 19F29FD010864-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

It appears that sge.net did something strange.  I have notified Paul...

Blake

> -----Original Message-----
> From:	Bob Jueneman [SMTP:[e-mail]]
> Sent:	Tuesday, September 01, 1998 10:55 AM
> To:	[e-mail]; [e-mail]; [e-mail]
> Subject:	Re: 42nd meeting
> 
> Is there something wrong with my mail package?
> 
> All I'm seeing on several messages is the following -- 
> maybe it's the joke of the day?
> 
> Bob
> 
> >>> John Pawling <[e-mail]> 08/31 8:09 AM >>>
> --AAA08737.904575102/kryptonite.sge.net--
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19792 for ietf-smime-bks; Tue, 1 Sep 1998 11:32:42 -0700 (PDT)
Received: from terisa-bh.terisa.com (terisa-bh.terisa.COM [205.226.38.66]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA19788 for <[e-mail]>; Tue, 1 Sep 1998 11:32:41 -0700 (PDT)
Received: (from uucp@localhost) by terisa-bh.terisa.com (8.6.12/8.6.11) id LAA18294; Tue, 1 Sep 1998 11:37:14 -0700
Received: from itech.terisa.com by terisa-bh.terisa.com via smap (3.2) id xma018289; Tue, 1 Sep 98 11:36:48 -0700
Received: from kmac.daisy (kmac.terisa.COM [205.226.39.35]) by itech.terisa.com (8.8.5/8.6.4) with SMTP id LAA28979; Tue, 1 Sep 1998 11:36:49 -0700 (PDT)
Received: by kmac.daisy (4.1/SMI-4.1) id AA11737; Tue, 1 Sep 98 11:36:49 PDT
To: Dr Stephen Henson <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: RC2 Keylength Strawpoll
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: EKR <[e-mail]>
Date: 01 Sep 1998 11:36:48 -0700
In-Reply-To: Dr Stephen Henson's message of "Tue, 01 Sep 1998 18:50:27 +0100"
Message-Id: <[e-mail]>
Lines: 90
X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

Dr Stephen Henson <[e-mail]> writes:

> EKR wrote:
> > 
> > Dr Stephen Henson <[e-mail]> writes:
> > 
> > >
> > > I propose this option not because its the best but because its what the
> > > two versions I've tested use: viz Netscape Messenger and Microsoft
> > > Outlook.
> > Representatives from both companies are here. It seems to me best
> > to see what their opinions are.
> > 
> 
> As I've said before. I know they use X/8 on send. I'm not expecting
> anyone to just take my word for it. I can demonstrate this to anyone who
> doubts it.
There are two primary reasons to be concerned with current behavior:
1. Backwards compatibility
Provided that they are prepared to accept arbitrary keylength
on receive, this isn't an issue. They'll have to change their
code to accomodate S/MIMEv3 ANYWAY, so they can change
this behavior as well.
2. Implementation hassle for the programmers.
Often, changing one's behavior is a hassle. Sometimes it's not.
I expect that the Netscape and Microsoft representatives
can take this into account when voting. 

It's not that I don't believe you about what Netscape and Microsoft
do. I just don't think it's that relevant.

> > IMHO, anyone who assumes X/8 when receiving has broken the cardinal
> > rule of being liberal in what you accept. Sending is a different
> > issue.
> > 
> 
> Yes I suppose that could be argued. Of course a "hands up whose software
> is broken" question may bring a limited response :-)
> 
> In some crypto libraries (SSLeay for example) you specify the unwrapping
> cipher when you unwrap a key with RSA. In the case of RC2 with 40 bits
> this specifies the effective bits and key size. The key size is then
> used as an additional integrity check on the decrypted RSA block.
In the face of the Million Message attack, this no longer
seems like such a great idea.

> Oh BTW I did some tests on Netscape and Outlook 98 anyway. As I said
> they both use X/8 on send but neither assumes X/8 on receive. So that's
> two implementations a fixed keysize wont break anyway...
> 
> > > As for this being more complicated to code and test I'd say that depends
> > > on the implementation. Currently, for example, SSLeay would need some
> > > modification to support option 2 with its envelope routines whereas
> > > option 1 is already supported.
> > That's not a reasonable standard. Clearly, any change is more
> > difficult to develop and test than no change. That's why we
> > take current practice into account. The issue with development
> > and test assumes you're starting from scratch. From THAT
> > perspective fixed is easier.
> 
> Well current practice seems to be X/8 on send with the implementations
> I've tested. Anyone know of anything that doesn't use X/8 on send? 
At Chicago, Blake asserted that a number of implementationd o other
things. Perhaps he'd be willing to speak up.

> In any case CMS needs an additional note if fixed keylength is adopted.
> Something like it MUST be fixed if key agreement is used for any
> recipient used and SHOULD|MUST|MAY (Comments?) if no recpients use key
> agreement.
Nonsense. Provided that all recipients will accept a fixed
length key, MUST is perfectly acceptable in all cases.
> If this isn't stated then we either need a standard for key lengths
> larger than 128 or an absolute prohibition of a key length greater than
> 128 bits for RC2.
This would be fine with me.

> IMHO prohibiting a keysize larger than 128 bits is not a good idea. Even
> if hardly anyone will ever use anything larger than 128 bits we should
> at least define a standard to handle this so people don't all do
> different and incompatible things.
On the contrary. I think it's a fantastic idea. People who want
a cipher that is 128 bits strong should choose something better
analyzed than RC2.

-Ekr
> 

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19411 for ietf-smime-bks; Tue, 1 Sep 1998 10:54:58 -0700 (PDT)
Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA19407 for <[e-mail]>; Tue, 1 Sep 1998 10:54:57 -0700 (PDT)
Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Tue, 01 Sep 1998 11:55:20 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 01 Sep 1998 11:54:46 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: 42nd meeting
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA19408
Sender: [e-mail]
Precedence: bulk

Is there something wrong with my mail package?

All I'm seeing on several messages is the following -- 
maybe it's the joke of the day?

Bob

>>> John Pawling <[e-mail]> 08/31 8:09 AM >>>
--AAA08737.904575102/kryptonite.sge.net--





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19389 for ietf-smime-bks; Tue, 1 Sep 1998 10:53:09 -0700 (PDT)
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA19374 for <[e-mail]>; Tue, 1 Sep 1998 10:52:10 -0700 (PDT)
Received: from (drh-consultancy.demon.co.uk) [193.237.150.98]  by post.mail.demon.net with esmtp (Exim 1.82 #2) id 0zDuff-0007FS-00; Tue, 1 Sep 1998 17:56:47 +0000
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 18:50:27 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: RC2 Keylength Strawpoll
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

EKR wrote:
> 
> Dr Stephen Henson <[e-mail]> writes:
> 
> >
> > I propose this option not because its the best but because its what the
> > two versions I've tested use: viz Netscape Messenger and Microsoft
> > Outlook.
> Representatives from both companies are here. It seems to me best
> to see what their opinions are.
> 

As I've said before. I know they use X/8 on send. I'm not expecting
anyone to just take my word for it. I can demonstrate this to anyone who
doubts it.

> > If you permit a larger key length then it may break an existing
> > implementation that assumes that the the keylength is X/8. It would
> > break mine for example but I can fix that.
> >
> > I can't comment on whether the above implementations assume X/8, can
> > anyone else? If no one knows then I can do some tests and post the
> > results back here.
> IMHO, anyone who assumes X/8 when receiving has broken the cardinal
> rule of being liberal in what you accept. Sending is a different
> issue.
> 

Yes I suppose that could be argued. Of course a "hands up whose software
is broken" question may bring a limited response :-)

In some crypto libraries (SSLeay for example) you specify the unwrapping
cipher when you unwrap a key with RSA. In the case of RC2 with 40 bits
this specifies the effective bits and key size. The key size is then
used as an additional integrity check on the decrypted RSA block.

Using the keysize as an integrity check is IMHO not unreasonable but
this would make things difficult if the keysize is not known in advance. 
As to how many implementations or crypto libraries this affects I've no
idea...

Oh BTW I did some tests on Netscape and Outlook 98 anyway. As I said
they both use X/8 on send but neither assumes X/8 on receive. So that's
two implementations a fixed keysize wont break anyway...

> > As for this being more complicated to code and test I'd say that depends
> > on the implementation. Currently, for example, SSLeay would need some
> > modification to support option 2 with its envelope routines whereas
> > option 1 is already supported.
> That's not a reasonable standard. Clearly, any change is more
> difficult to develop and test than no change. That's why we
> take current practice into account. The issue with development
> and test assumes you're starting from scratch. From THAT
> perspective fixed is easier.

Well current practice seems to be X/8 on send with the implementations
I've tested. Anyone know of anything that doesn't use X/8 on send? 

In any case CMS needs an additional note if fixed keylength is adopted.
Something like it MUST be fixed if key agreement is used for any
recipient used and SHOULD|MUST|MAY (Comments?) if no recpients use key
agreement.

> > If option 2 is taken then what should the fixed keylength be? If we set
> > it as (for example) 128 bits then that restricts anyone who wishes to
> > use more. So you couldn't just say "fixed keylength" you'd have to say
> > for example: "the keylength is rounded up to the nearest multiple of 16
> > to X/8". One conclusion to this is, of course, you might as well have a
> > variable key length to begin with.
> This is a non-problem. The permissible RC2 keylengths in S/MIME are
> 40,64, and 128. Consequently, fixed 128 will work just fine.
> 

I may have missed something here but is this explicitly stated anywhere?
I know that 40, 64 and 128 are given as examples but the RC2 spec
permits larger keysizes as does the S/MIME capabilities attribute.

If this isn't stated then we either need a standard for key lengths
larger than 128 or an absolute prohibition of a key length greater than
128 bits for RC2.

IMHO prohibiting a keysize larger than 128 bits is not a good idea. Even
if hardly anyone will ever use anything larger than 128 bits we should
at least define a standard to handle this so people don't all do
different and incompatible things.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA18211 for ietf-smime-bks; Tue, 1 Sep 1998 08:19:07 -0700 (PDT)
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA18207 for <[e-mail]>; Tue, 1 Sep 1998 08:19:05 -0700 (PDT)
Received: from (drh-consultancy.demon.co.uk) [193.237.150.98]  by post.mail.demon.net with esmtp (Exim 1.82 #2) id 0zDsHU-0007U0-00; Tue, 1 Sep 1998 15:23:41 +0000
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 16:21:32 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: CMS key wrapping suggestion.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Apologies if this has been mentioned before but in the last version of
the key wrapping standard I have:

5.  Generate the number of pad octets necessary to make the
    result a multiple of the key-encryption algorithm block
    size, then append them to the result.

This sounds as though it is incompatible with PKCS padding which adds a
block of padding octets if the result is already a multiple of the block
size.

Since (from what I can see) symmetric algorithms for the message
encryption use PKCS padding (see CMS 6.3) I see no real reason why it
shouldn't be also applied here: it does add a small additional integrity
check. Otherwise two different padding schemes would be applied, no
padding (for key wrap) and PKCS padding (for content encryption).

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA17849 for ietf-smime-bks; Tue, 1 Sep 1998 07:38:29 -0700 (PDT)
Received: from terisa-bh.terisa.com (terisa-bh.terisa.COM [205.226.38.66]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA17845 for <[e-mail]>; Tue, 1 Sep 1998 07:38:29 -0700 (PDT)
Received: (from uucp@localhost) by terisa-bh.terisa.com (8.6.12/8.6.11) id HAA12600; Tue, 1 Sep 1998 07:42:43 -0700
Received: from itech.terisa.com by terisa-bh.terisa.com via smap (3.2) id xma012598; Tue, 1 Sep 98 07:42:37 -0700
Received: from kmac.daisy (kmac.terisa.COM [205.226.39.35]) by itech.terisa.com (8.8.5/8.6.4) with SMTP id HAA26065; Tue, 1 Sep 1998 07:42:37 -0700 (PDT)
Received: by kmac.daisy (4.1/SMI-4.1) id AA11686; Tue, 1 Sep 98 07:42:37 PDT
To: Dr Stephen Henson <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: RC2 Keylength Strawpoll
References: <[e-mail]> <[e-mail]>
From: EKR <[e-mail]>
Date: 01 Sep 1998 07:42:36 -0700
In-Reply-To: Dr Stephen Henson's message of "Tue, 01 Sep 1998 12:18:39 +0100"
Message-Id: <[e-mail]>
Lines: 52
X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

Dr Stephen Henson <[e-mail]> writes:

> Sorry I missed the comment about discussion being as a reply. Anyway
> here are my original comments...
> 
> I propose this option not because its the best but because its what the
> two versions I've tested use: viz Netscape Messenger and Microsoft
> Outlook.
Representatives from both companies are here. It seems to me best
to see what their opinions are.

> If you permit a larger key length then it may break an existing
> implementation that assumes that the the keylength is X/8. It would
> break mine for example but I can fix that. 
>
> I can't comment on whether the above implementations assume X/8, can
> anyone else? If no one knows then I can do some tests and post the
> results back here.
IMHO, anyone who assumes X/8 when receiving has broken the cardinal
rule of being liberal in what you accept. Sending is a different
issue.

> As for this being more complicated to code and test I'd say that depends
> on the implementation. Currently, for example, SSLeay would need some
> modification to support option 2 with its envelope routines whereas
> option 1 is already supported.
That's not a reasonable standard. Clearly, any change is more
difficult to develop and test than no change. That's why we
take current practice into account. The issue with development
and test assumes you're starting from scratch. From THAT 
perspective fixed is easier.
> There is a standard that that sort of defines it. The standard I'm
> referring to is PKCS#12 password based encryption. In this case the
> keylength is specifically implied by the algorithm as X/8.
> 
> Since my original message I've thought of something else...
> 
> If option 2 is taken then what should the fixed keylength be? If we set
> it as (for example) 128 bits then that restricts anyone who wishes to
> use more. So you couldn't just say "fixed keylength" you'd have to say
> for example: "the keylength is rounded up to the nearest multiple of 16
> to X/8". One conclusion to this is, of course, you might as well have a
> variable key length to begin with. 
This is a non-problem. The permissible RC2 keylengths in S/MIME are
40,64, and 128. Consequently, fixed 128 will work just fine.

-Ekr


-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA16498 for ietf-smime-bks; Tue, 1 Sep 1998 04:15:41 -0700 (PDT)
Received: from post.mail.demon.net (post-11.mail.demon.net [194.217.242.40]) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA16494 for <[e-mail]>; Tue, 1 Sep 1998 04:15:39 -0700 (PDT)
Received: from (drh-consultancy.demon.co.uk) [193.237.150.98]  by post.mail.demon.net with esmtp (Exim 1.82 #2) id 0zDoTv-0007F6-00; Tue, 1 Sep 1998 11:20:15 +0000
Message-ID: <[e-mail]>
Date: Tue, 01 Sep 1998 12:18:39 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: RC2 Keylength Strawpoll
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Sorry I missed the comment about discussion being as a reply. Anyway
here are my original comments...

I propose this option not because its the best but because its what the
two versions I've tested use: viz Netscape Messenger and Microsoft
Outlook.

If you permit a larger key length then it may break an existing
implementation that assumes that the the keylength is X/8. It would
break mine for example but I can fix that. 

I can't comment on whether the above implementations assume X/8, can
anyone else? If no one knows then I can do some tests and post the
results back here.

As for this being more complicated to code and test I'd say that depends
on the implementation. Currently, for example, SSLeay would need some
modification to support option 2 with its envelope routines whereas
option 1 is already supported.

There is a standard that that sort of defines it. The standard I'm
referring to is PKCS#12 password based encryption. In this case the
keylength is specifically implied by the algorithm as X/8.

Since my original message I've thought of something else...

If option 2 is taken then what should the fixed keylength be? If we set
it as (for example) 128 bits then that restricts anyone who wishes to
use more. So you couldn't just say "fixed keylength" you'd have to say
for example: "the keylength is rounded up to the nearest multiple of 16
to X/8". One conclusion to this is, of course, you might as well have a
variable key length to begin with. 

There is a third option: include the keylength in the CMS as an OPTIONAL
parameter with a default of, say, X/8 if not present.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA14406 for ietf-smime-bks; Tue, 1 Sep 1998 03:02:36 -0700 (PDT)
Received: from nic.incolumitas.se (nic.incolumitas.se [194.52.80.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA14402 for <[e-mail]>; Tue, 1 Sep 1998 03:02:33 -0700 (PDT)
Received: (from jang@localhost) by nic.incolumitas.se (8.8.7/8.8.7) id MAA15706; Tue, 1 Sep 1998 12:07:53 +0200 (MET DST)
To: [e-mail]
Subject: OPTION 1: RC2 Key Length X/8
From: [e-mail] (Jan Garefelt)
Date: 01 Sep 1998 12:07:52 +0200
Message-ID: <[e-mail]>
Lines: 0
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: [e-mail]
Precedence: bulk


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA14135 for ietf-smime-bks; Tue, 1 Sep 1998 02:03:57 -0700 (PDT)
Received: from titanium.sge.net (titanium.sge.net [152.91.9.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA14131 for <[e-mail]>; Tue, 1 Sep 1998 02:03:54 -0700 (PDT)
Received: (from uucp@localhost) by titanium.sge.net (8.8.5/8.8.5) id TAA18498; Tue, 1 Sep 1998 19:06:59 +1000 (EST)
Received: from kryptonite.sge.net(10.1.2.11) by titanium.sge.net via smap (3.2) id xma018477; Tue, 1 Sep 98 19:06:48 +1000
Received: from amber (ice-int2.sge.net [10.1.2.254]) by kryptonite.sge.net (8.8.8/8.8.8) with SMTP id TAA14498; Tue, 1 Sep 1998 19:06:48 +1000 (EST)
Date: Mon, 31 Aug 1998 10:09:44 -0400
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Koujirou Wakabayashi <[e-mail]>, [e-mail]
From: [e-mail] (John Pawling)
Subject: Re: 42nd meeting
Sender: [e-mail]
Precedence: bulk

--AAA08737.904575102/kryptonite.sge.net--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA13631 for ietf-smime-bks; Tue, 1 Sep 1998 00:23:53 -0700 (PDT)
Received: from titanium.sge.net (titanium.sge.net [152.91.9.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA13627 for <[e-mail]>; Tue, 1 Sep 1998 00:23:50 -0700 (PDT)
Received: (from uucp@localhost) by titanium.sge.net (8.8.5/8.8.5) id RAA15105 for <[e-mail]>; Tue, 1 Sep 1998 17:27:55 +1000 (EST)
Received: from kryptonite.sge.net(10.1.2.11) by titanium.sge.net via smap (3.2) id xma014965; Tue, 1 Sep 98 17:27:23 +1000
Received: from amber (ice-int2.sge.net [10.1.2.254]) by kryptonite.sge.net (8.8.8/8.8.8) with SMTP id RAA04829 for <[e-mail]>; Tue, 1 Sep 1998 17:27:17 +1000 (EST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: 42nd meeting
Date: Mon, 31 Aug 1998 17:29:48 +0900
From: Koujirou Wakabayashi <[e-mail]>
Sender: [e-mail]
Precedence: bulk

--TAA23930.904555102/kryptonite.sge.net--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA13569 for ietf-smime-bks; Tue, 1 Sep 1998 00:16:14 -0700 (PDT)
Received: from titanium.sge.net (titanium.sge.net [152.91.9.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA13565 for <[e-mail]>; Tue, 1 Sep 1998 00:16:11 -0700 (PDT)
Received: (from uucp@localhost) by titanium.sge.net (8.8.5/8.8.5) id RAA12545 for <[e-mail]>; Tue, 1 Sep 1998 17:20:16 +1000 (EST)
Received: from kryptonite.sge.net(10.1.2.11) by titanium.sge.net via smap (3.2) id xma012226; Tue, 1 Sep 98 17:20:01 +1000
Received: from amber (ice-int2.sge.net [10.1.2.254]) by kryptonite.sge.net (8.8.8/8.8.8) with SMTP id RAA01874 for <[e-mail]>; Tue, 1 Sep 1998 17:20:01 +1000 (EST)
Message-Id: <[e-mail]>
X-Authentication-Warning: robotmail.ne.jp: oracle set sender to [e-mail] using -f
X-RM-Status: 9
X-RM-GetFrom: Sent
Date: Mon, 31 Aug 1998 17:12:19 +0900 (JST)
From: "=?ISO-2022-JP?B?GyRCPGNOUxsoQg==?= =?ISO-2022-JP?B?GyRCOSc8IU86GyhC?=" <[e-mail]>
To: [e-mail]
Subject: 42nd meeting
MIME-version: 1.0
X-Mailer: RobotMail ver. 1.0 b6
X-URL: http://robotmail.ne.jp/
X-Message: ------ This mail was sent by RobotMail. -----
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk

--TAA23521.904554737/kryptonite.sge.net--