Subject: Re: Encrypted mail in Limbo
From: "Anders Rundgren" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Thu, 30 Jan 2003 12:34:12 +0100
List-Id: <ietf-smime.imc.org>

Peter,
Actually I have some doubts about encrypted mail as a mass-
activity in general.  It far too complex to handle.  DOMSEC
would have been much better for the majority of messages.

Anyway, in order to aquire encryption keys in a reasonable
way from somebody you only have (an hopefully working)
e-mail address to, you should be able to search pre-defined
places using CertStore or go through DNS.

But I don't think that this will be a killer due to the privacy
issues, as well as to the fact that the user may have a TTP-
issued certificate.  Therefore I suggest a number of possible
additions:

1. a new URL-type: signed internet mail address (SIMA)
2. a new optional SMTP header: SIMA
3. a new SubjectAltName OtherName: SIMA

Then you have three ways of distributing (indirect) keys, 
automagically in ordinary mail, as explicit URL text in mails etc., 
and automagically through digitally signed messages.

Without any _MAJOR_ improvements in this area, I feel that
encryption certificate lookup will never become mainstream
exactly in the way as encrypted mail is not today.

Anders

----- Original Message ----- 
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, January 30, 2003 11:28
Subject: Re: Encrypted mail in Limbo

"Anders Rundgren" <[email-masked]> writes:

>As you probably have noticed, "authenticated" URLs are very common in many
>places like for verifying e-mail addresses, often in connection to a certain
>registration event.
>
>In order to use other peoples' public keys for e-mail encryption, I claim
>that none of the proposed systems [1] work well except in very local (or very
>open) places due to privacy issues [2].
>
>The problem is how to distribute "semi-secret" information in a simple way.
>It seems like a signed mail-address MIME-type could be required for out-of-
>band distribution using a client "click" only.
>
>  566655fe76adr5fyyeed655:[email-masked]

Oh, I see what you mean now.  Hmm, I thought I had something in the text about
people using the HTTP-access thing as a static URL to identify a cert, but I
can't find any trace of it.  What I mean here is that a CA or helpdesk could
mail a user their cert URL (say certificates.blah.com/search.cgi?email=
luser%40blah.com) and all they have to do is click on it and they're done,
rather than hunt around some CA's web pages for it.  Since every browser and
most mail software can do an HTTP GET, this gets them their cert
automatically.  What you're proposing could easily go in the implementation
notes as another suggested way to do things, it's a nice variation on the
mailed-URL idea.  Or you could do your own RFC if you preferred that.  

I assume what you're proposing is that the user gets told to fetch:

  certificates.blah.com/search.cgi?x-certMAC=qwertyuiop

(using the 'x-' extension mechanism) by the CA, and the CA can map that to the
required cert, thus providing the privacy/authenticated-URL feature.  Or:

  certificates.blah.com/search.cgi?x-encryptedCertID=qwertyuiop

That's a cool idea, thanks for suggesting it.

Peter.

Date: Thu, 30 Jan 2003 23:28:52 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Encrypted mail in Limbo
Sender: [email-masked]

"Anders Rundgren" <[email-masked]> writes:

>As you probably have noticed, "authenticated" URLs are very common in many
>places like for verifying e-mail addresses, often in connection to a certain
>registration event.
>
>In order to use other peoples' public keys for e-mail encryption, I claim
>that none of the proposed systems [1] work well except in very local (or very
>open) places due to privacy issues [2].
>
>The problem is how to distribute "semi-secret" information in a simple way.
>It seems like a signed mail-address MIME-type could be required for out-of-
>band distribution using a client "click" only.
>
>  566655fe76adr5fyyeed655:[email-masked]

Oh, I see what you mean now.  Hmm, I thought I had something in the text about
people using the HTTP-access thing as a static URL to identify a cert, but I
can't find any trace of it.  What I mean here is that a CA or helpdesk could
mail a user their cert URL (say certificates.blah.com/search.cgi?email=
luser%40blah.com) and all they have to do is click on it and they're done,
rather than hunt around some CA's web pages for it.  Since every browser and
most mail software can do an HTTP GET, this gets them their cert
automatically.  What you're proposing could easily go in the implementation
notes as another suggested way to do things, it's a nice variation on the
mailed-URL idea.  Or you could do your own RFC if you preferred that.  

I assume what you're proposing is that the user gets told to fetch:

  certificates.blah.com/search.cgi?x-certMAC=qwertyuiop

(using the 'x-' extension mechanism) by the CA, and the CA can map that to the
required cert, thus providing the privacy/authenticated-URL feature.  Or:

  certificates.blah.com/search.cgi?x-encryptedCertID=qwertyuiop

That's a cool idea, thanks for suggesting it.

Peter.

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Peter Gutmann" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>
Subject: Encrypted mail in Limbo
Date: Thu, 30 Jan 2003 10:17:21 +0100
Sender: [email-masked]

As you probably have noticed, "authenticated" URLs are very
common in many places like for verifying e-mail addresses, often
in connection to a certain registration event.

In order to use other peoples' public keys for e-mail encryption,
I claim that none of the proposed systems [1] work well except in very
local (or very open) places due to privacy issues [2].

The problem is how to distribute "semi-secret" information in a
simple way.    It seems like a signed mail-address MIME-type could
be required for out-of-band distribution using a client "click" only.

  566655fe76adr5fyyeed655:[email-masked]

Anders R

1] LDAP, XKMS, HTTP CertStore

2] X.500 directories is a bad idea from a privacy point of view.
That is, you typically have a limited set of trusted parties that
you may need to send encrypted messages to.   These partnerships 
have been established in ad-hoc out-of-band ways.  However, to
distribute passwords, client certificates for partners to use for
accessing your public key would be awfully complicated. 
"Authenticated" (hmac-signed lookup data) represent a reasonable
compromise between security and privacy.  Semi-secret data...

Or do you think that corporatations will publish keys for anybody
to access?  I'm doubt they will, except for a few contact "persons"
like [email-masked] :-)

From: "Khaja Ahmed" <[email-masked]>
To: <[email-masked]>
Subject: S/MIME interoperability tests
Date: Fri, 24 Jan 2003 21:07:48 -0800
Importance: Normal
Sender: [email-masked]

I am curious about the state of interoperability between clients as regards
basic s/mime capabilities like sending clear singed messages.  Could some
kindly soul direct me to the latest S/MIME interoperability test results?  I
know NIST had done a while back but not sure if one was done more recently
and where the report would be. One document discussing the 'Characteristics
that affect interoperability' is more the 4 years old.  I suspect things
have improved at least a bit since then.

Can a simple clear signed message created by any client be processed (1.
message understood/parsed successfully and 2. signature verified correctly)
by every other major client?  Any answers that can separately deal with the
message parsing aspect of this vs. the certificate processing part would be
great.

I'll be grateful for any light that can be shed on this subject.

Khaja

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Wrapping an HMAC key with a Triple-DES Key or an  AES Key to Proposed Standard
Reply-to: [email-masked]
Date: Fri, 24 Jan 2003 18:57:50 -0500
Sender: [email-masked]

The IESG has received a request from the S/MIME Mail Security Working 
Group to consider Wrapping an HMAC key with a Triple-DES Key or an AES 
Key <draft-ietf-smime-hmac-key-wrap-00.txt> as a Proposed Standard.  

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

Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-hmac-key-wrap-00.txt

Date: Thu, 23 Jan 2003 09:30:10 -0500
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Error in RFC 3369
Sender: [email-masked]

RFC 3369 contains the following reference:

    [CMSALG]    Housley, R., "Cryptographic Message Syntax (CMS)
                Algorithms", RFC 3269, August 2002.

The RFC number is incorrect.  The correct RFC number is 3370.

Russ

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Elanor Foley'" <[email-masked]>, <[email-masked]>
Subject: RE: Multiple signers and changing receipt requests
Date: Tue, 21 Jan 2003 23:44:38 -0800
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C2C1A7.0FFB6CB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Elanor,
 
Congratulations,  I believe you have uncovered a flow in ESS that
requires an update to be made to the document.
 
If you have two people signing at the same time, then it would be
possible to construct the ReceiptRequest so that it goes to both
signers.  This means that it could be copied by the second signing
operation and the same data would be in both signatures.
 
If you have a mail list agent adding a signing layer, it can use the
mlReciptPolicy and modify the requested receipt from the inside.
 
We do not however have an adequate response for the workflow case.  That
is a person at a later date wants to sign the object and modify the
RecieptRequest.  This person cannot use a ReceiptRequest attribute since
the first person would not know who to include in the receiptRequest
(and indeed should not until that person processes the item in the
workflow).  If the secondary person were to use an mlReceiptPolicy, the
receipt would be re-directed properly, however any MLAs or equivalent
items would strip the secondary person's signature as the rules state
you strip all signature layers with the mlReceiptPolicy attribute.  This
means that the secondary persons signature would be lost.
 
Is there anyone other than myself that feels this issue needs to be
addressed properly?
 
jim

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Elanor Foley
Sent: Tuesday, January 07, 2003 8:39 AM
To: [email-masked]'
Subject: Multiple signers and changing receipt requests

Hello,
 
As I understand CMS rfc2630 and ESS rfc2634, it is possible to create a
SignedData with multiple signers (one signedData with multiple
signerInfos). Say one of these signers has included a ReceiptRequest in
his signedAttributes. How would another (subsequent) signer also add a
ReceiptRequest or modify the existing one? It looks like there is no
provision for this. The first signer to request a receipt pre-empts any
other signer who may wish a different receipt request. The receipt
request itself cannot be modified because it is a signed attribute. Can
subsequent signers pretend to be an MLAgent and add a mlReceiptPolicy?
 
Also, I find myself confused by statements in sections 2.2.1 and 2.3
from the ESS rfc. These are highlighted by asterisks below

ESS 2.1 Signed Receipt Concepts

   The originator of a message may request a signed receipt from the
   message's recipients. 
 
ESS 2.2 Receipt Request Creation

   <snip>
Only one receiptRequest attribute can be included in the
   signedAttributes of a SignerInfo.

ESS 2.2.1 Multiple Receipt Requests

   There can be multiple SignerInfos within a SignedData object, and
   each SignerInfo may include signedAttributes. Therefore, a single
   SignedData object may include multiple SignerInfos, each SignerInfo
   having a receiptRequest attribute. For example, an originator can
   send a signed message with two SignerInfos, one containing a DSS
   signature, the other containing an RSA signature.

   Each recipient SHOULD return only one signed receipt.

   /***Not all of the SignerInfos need to include receipt requests, but
in
   all of the SignerInfos that do contain receipt requests, the receipt
   requests MUST be identical.***/

But
 
ESS 2.3 Receipt Request Processing

   A receiptRequest is associated only with the SignerInfo object to
   which the receipt request attribute is directly attached. Receiving
   software SHOULD examine the signedAttributes field of each of the
   SignerInfos for which it verifies a signature in the innermost
   signedData object to determine if a receipt is requested. /***This
may
   result in the receiving agent processing multiple receiptRequest
   attributes included in a single SignedData object, such as requests
   made from different people who signed the object in parallel.***/

The "different people" are not making different requests? They're just
copying the first person's receipt request?

Thanks for your help,
 -    Lnr

____________________________________________ 
Lnr Foley 
Baltimore Technologies
Web:  <http://www.baltimore.com/> http://www.baltimore.com 
_____________________________________________ 

 

------=_NextPart_000_0013_01C2C1A7.0FFB6CB0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D292223507-22012003><FONT face=3DArial color=3D#0000ff =

size=3D2>Elanor,</FONT></SPAN></DIV>
<DIV><SPAN class=3D292223507-22012003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D292223507-22012003><FONT face=3DArial color=3D#0000ff =

size=3D2>Congratulations,&nbsp; I believe you have uncovered a flow in =
ESS that=20
requires an update to be made to the document.</FONT></SPAN></DIV>
<DIV><SPAN class=3D292223507-22012003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D292223507-22012003><FONT face=3DArial color=3D#0000ff =
size=3D2>If you=20
have two people signing at the same time, then it would be possible to =
construct=20
the ReceiptRequest so that it goes to both signers.&nbsp; This means =
that it=20
could be copied by the second signing operation and the same data would =
be in=20
both signatures.</FONT></SPAN></DIV>
<DIV><SPAN class=3D292223507-22012003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D292223507-22012003><FONT face=3DArial color=3D#0000ff =
size=3D2>If you=20
have a mail list agent adding a signing layer, it can use the =
mlReciptPolicy and=20
modify the requested receipt from the inside.</FONT></SPAN></DIV>
<DIV><SPAN class=3D292223507-22012003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D292223507-22012003><FONT face=3DArial color=3D#0000ff =
size=3D2>We do=20
not however have an adequate response for the workflow case.&nbsp; That =
is a=20
person at a later date wants to sign the object and modify the=20
RecieptRequest.&nbsp; This person cannot use a ReceiptRequest attribute =
since=20
the first person would not know who to include in the receiptRequest =
(and indeed=20
should not until that person processes the item in the workflow).&nbsp; =
If the=20
secondary person were to use an mlReceiptPolicy, the receipt would be=20
re-directed properly, however any MLAs or equivalent items would strip =
the=20
secondary person's signature as the rules state you strip all signature =
layers=20
with the mlReceiptPolicy attribute.&nbsp; This means that the secondary =
persons=20
signature would be lost.</FONT></SPAN></DIV>
<DIV><SPAN class=3D292223507-22012003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D292223507-22012003><FONT face=3DArial color=3D#0000ff =
size=3D2>Is=20
there anyone other than myself that feels this issue needs to be =
addressed=20
properly?</FONT></SPAN></DIV>
<DIV><SPAN class=3D292223507-22012003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D292223507-22012003><FONT face=3DArial color=3D#0000ff =

size=3D2>jim</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Elanor Foley<BR><B>Sent:</B> Tuesday, January 07, 2003 =
8:39=20
  AM<BR><B>To:</B> [email-masked]'<BR><B>Subject:</B> Multiple =
signers and=20
  changing receipt requests<BR><BR></FONT></DIV>
  <DIV><CODE><FONT size=3D3><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
  class=3D320594115-07012003>Hello,</SPAN></FONT></FONT></CODE></DIV>
  <DIV><CODE><FONT size=3D3><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
  class=3D320594115-07012003></SPAN></FONT></FONT></CODE>&nbsp;</DIV>
  <DIV><CODE><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D320594115-07012003>As I understand CMS rfc2630 and ESS =
rfc2634, it is=20
  possible to create a SignedData with multiple signers (one signedData =
with=20
  multiple signerInfos). Say one of these signers has included a =
ReceiptRequest=20
  in his signedAttributes. How would another (subsequent) signer also =
add a=20
  ReceiptRequest<SPAN class=3D787233516-07012003> or modify the existing =

  one</SPAN>? It looks like there is no provision for this. The first =
signer to=20
  request a receipt pre-empts any other signer who may wish a different =
receipt=20
  request.<SPAN class=3D787233516-07012003>&nbsp;The receipt request =
itself cannot=20
  be modified because it is a signed =
attribute.&nbsp;</SPAN>Can&nbsp;subsequent=20
  signers&nbsp;pretend to be an MLAgent and add a <FONT=20
  color=3D#000000>mlReceiptPolicy</FONT>?</SPAN></FONT></CODE></DIV>
  <DIV><CODE><FONT size=3D3><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
  class=3D320594115-07012003></SPAN></FONT></FONT></CODE>&nbsp;</DIV>
  <DIV><CODE><FONT size=3D3><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
  class=3D320594115-07012003>Also, I find myself confused by statements =
in=20
  sections 2.2.1 and 2.3 from the ESS rfc. These are highlighted by =
asterisks=20
  below</SPAN></FONT></FONT></CODE></DIV>
  <DIV>
  <DIV><CODE><FONT size=3D3><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
  =
class=3D320594115-07012003></SPAN></FONT></FONT></CODE></DIV><CODE><FONT =

  size=3D3><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D320594115-07012003></SPAN></FONT></FONT></CODE></DIV>
  <DIV><CODE><FONT face=3DArial><SPAN class=3D320594115-07012003>ESS 2.1 =
Signed=20
  Receipt Concepts<BR><BR>&nbsp;&nbsp; The originator of a message may =
request a=20
  signed receipt from the<BR>&nbsp;&nbsp; message's recipients.=20
  </SPAN></FONT></CODE></DIV>
  <DIV><CODE><FONT face=3DArial><SPAN=20
  class=3D320594115-07012003></SPAN></FONT></CODE>&nbsp;</DIV>
  <DIV><CODE><FONT face=3DArial><SPAN class=3D320594115-07012003>ESS 2.2 =
Receipt=20
  Request Creation<BR><BR>&nbsp;&nbsp; =
&lt;snip&gt;</SPAN></FONT></CODE></DIV>
  <DIV><CODE><FONT face=3DArial><SPAN class=3D320594115-07012003>Only =
one=20
  receiptRequest attribute can be included in the<BR>&nbsp;&nbsp;=20
  signedAttributes of a SignerInfo.<BR></DIV></SPAN></FONT></CODE>
  <DIV><CODE><FONT face=3DArial><SPAN class=3D320594115-07012003>ESS =
2.2.1 Multiple=20
  Receipt Requests<BR><BR>&nbsp;&nbsp; There can be multiple SignerInfos =
within=20
  a SignedData object, and<BR>&nbsp;&nbsp; each SignerInfo may include=20
  signedAttributes. Therefore, a single<BR>&nbsp;&nbsp; SignedData =
object may=20
  include multiple SignerInfos, each SignerInfo<BR>&nbsp;&nbsp; having a =

  receiptRequest attribute. For example, an originator =
can<BR>&nbsp;&nbsp; send=20
  a signed message with two SignerInfos, one containing a =
DSS<BR>&nbsp;&nbsp;=20
  signature, the other containing an RSA signature.<BR><BR>&nbsp;&nbsp; =
Each=20
  recipient SHOULD return only one signed receipt.<BR><BR>&nbsp;&nbsp; =
/***Not=20
  all of the SignerInfos need to include receipt requests, but=20
  in<BR>&nbsp;&nbsp; all of the SignerInfos that do contain receipt =
requests,=20
  the receipt<BR>&nbsp;&nbsp; requests MUST be=20
  identical.***/</SPAN></FONT></CODE></DIV>
  <DIV><CODE><FONT face=3DArial><SPAN=20
  class=3D320594115-07012003></SPAN></FONT></CODE>&nbsp;</DIV>
  <DIV><CODE><FONT size=3D+0><SPAN class=3D320594115-07012003><FONT =
color=3D#0000ff=20
  size=3D2></FONT>&nbsp;</DIV>
  <DIV><SPAN class=3D320594115-07012003></SPAN><FONT face=3DArial><FONT=20
  color=3D#0000ff><FONT size=3D2>B<SPAN=20
  class=3D320594115-07012003>ut</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
  class=3D320594115-07012003></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial><FONT face=3D"Courier New"><SPAN=20
  class=3D320594115-07012003>ESS 2.3 Receipt Request=20
  Processing<BR><BR>&nbsp;&nbsp; A receiptRequest is associated only =
with the=20
  SignerInfo object to<BR>&nbsp;&nbsp; which the receipt request =
attribute is=20
  directly attached. Receiving<BR>&nbsp;&nbsp; software SHOULD examine =
the=20
  signedAttributes field of each of the<BR>&nbsp;&nbsp; SignerInfos for =
which it=20
  verifies a signature in the innermost<BR>&nbsp;&nbsp; signedData =
object to=20
  determine if a receipt is requested. <FONT color=3D#ff0000><FONT=20
  color=3D#000000>/***This may<BR>&nbsp;&nbsp; result in the receiving =
agent=20
  processing multiple receiptRequest<BR>&nbsp;&nbsp; attributes included =
in a=20
  single SignedData object, such as requests<BR>&nbsp;&nbsp; made from =
different=20
  people who signed the object in=20
  parallel.***/</FONT><BR></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff size=3D2></FONT><FONT color=3D#0000ff =
size=3D2></FONT><FONT=20
  color=3D#0000ff size=3D2></FONT><BR></DIV></FONT></SPAN></FONT></CODE>
  <DIV><CODE><FONT size=3D3><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
  class=3D320594115-07012003><SPAN class=3D787233516-07012003>The =
"different people"=20
  are not making different requests? They're just copying the first =
person's=20
  receipt request?</SPAN></SPAN></FONT></FONT></CODE></DIV>
  <DIV><CODE><FONT size=3D3><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
  class=3D320594115-07012003><SPAN=20
  =
class=3D787233516-07012003></SPAN></SPAN></FONT></FONT></CODE>&nbsp;</DIV=
>
  <DIV><CODE><FONT size=3D3><FONT size=3D+0><SPAN =
class=3D320594115-07012003><SPAN=20
  class=3D787233516-07012003>
  <DIV><CODE><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D320594115-07012003><SPAN class=3D787233516-07012003>Thanks for =
your=20
  help,</SPAN></SPAN></FONT></CODE></DIV>
  <DIV><CODE><FONT size=3D+0><SPAN class=3D320594115-07012003><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><FONT size=3D2><SPAN =
class=3D787233516-07012003>&nbsp;-=20
  &nbsp;</SPAN><SPAN class=3D787233516-07012003>&nbsp;</SPAN>=20
  Lnr<BR></FONT></FONT></FONT><SPAN class=3D787233516-07012003>
  <P><FONT color=3D#0000ff><FONT face=3DArial=20
  size=3D2>____________________________________________ <BR>Lnr=20
  Foley&nbsp;<BR>Baltimore Technologies<BR>Web: </FONT><A=20
  href=3D"http://www.baltimore.com/" target=3D_blank><FONT face=3DArial=20
  size=3D2>http://www.baltimore.com</FONT></A><FONT face=3DArial =
size=3D2>=20
  <BR>_____________________________________________ =
</FONT></FONT></P><BR><FONT=20
  face=3DArial color=3D#0000ff=20
  =
size=3D2>&nbsp;</FONT></SPAN></SPAN></FONT></CODE></DIV></SPAN></SPAN></F=
ONT></DIV></BLOCKQUOTE></FONT></CODE></BODY></HTML>

------=_NextPart_000_0013_01C2C1A7.0FFB6CB0--

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Ryan Koh'" <[email-masked]>, <[email-masked]>
Subject: RE: Multiple symmetric algo-encrypted data in single S/MIME message
Date: Tue, 21 Jan 2003 22:45:19 -0800
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C2C19E.C70321E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Ryan,
 
The current CMS format used by S/MIME allows for only a single algorithm
to be used for encrypting the content.  While there are several
different ways around this, the only ones that I consider to be
practical are to either 1) send two messages as you presently do or 2)
install a Domain boundry server (ala RFC 3183) to change the build
encryption algorithm.
 
jim

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ryan Koh
Sent: Tuesday, January 21, 2003 10:03 PM
To: [email-masked]
Subject: Multiple symmetric algo-encrypted data in single S/MIME message

Hi

My organisation users need to communicate with 2 groups of users, on
different S/MIME secure mail systems.  The problem lies in them using
different symmetric algorithms for data encryption.  I am assessing
possibility of building a single mail client to compose and send S/MIME
messages to selected users on both nets, at the same time (i.e. at one
sending operation).  This means that there would logically be 2 sets of
encrypted blobs in the S/MIME message sent out, but I am not sure if
this is supported in S/MIME format.

The easy way out of course is to send out the same mails twice
separately, to users of each group, as what we are doing now.  This
however is neither efficient nor elegant.

Any suggestion/recommendation would be greatly appreciated.

Thanks

Ryan Koh

  _____  

<http://uk.yahoo.com/mail/tagline_xtra/?http://uk.docs.yahoo.com/mail_st
orage.html> With Yahoo! Mail you can get a bigger mailbox -- choose a
size that fits your needs

------=_NextPart_000_0009_01C2C19E.C70321E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D260434206-22012003><FONT face=3DArial color=3D#0000ff =

size=3D2>Ryan,</FONT></SPAN></DIV>
<DIV><SPAN class=3D260434206-22012003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D260434206-22012003><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
current CMS format used by S/MIME allows for only a single algorithm to =
be used=20
for encrypting the content.&nbsp; While there are several different ways =
around=20
this, the only ones that I consider to be practical are to either 1) =
send two=20
messages as you presently do or 2) install a Domain boundry server (ala =
RFC=20
3183) to change the build encryption algorithm.</FONT></SPAN></DIV>
<DIV><SPAN class=3D260434206-22012003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D260434206-22012003><FONT face=3DArial color=3D#0000ff =

size=3D2>jim</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Ryan Koh<BR><B>Sent:</B> Tuesday, January 21, 2003 10:03 =

  PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Multiple =
symmetric=20
  algo-encrypted data in single S/MIME message<BR><BR></FONT></DIV>
  <P>Hi</P>
  <P>My organisation users need to communicate with 2 groups of users, =
on=20
  different S/MIME secure mail systems.&nbsp; The problem lies in them =
using=20
  different symmetric&nbsp;algorithms for data encryption.&nbsp; I am =
assessing=20
  possibility of building a single mail client to compose and send =
S/MIME=20
  messages to selected users on both nets, at the same time (i.e. at one =
sending=20
  operation).&nbsp; This means that there would logically be 2 sets of =
encrypted=20
  blobs in the S/MIME message sent out, but I am not sure if this is =
supported=20
  in S/MIME format.</P>
  <P>The easy way out of course is to send out the same mails twice =
separately,=20
  to users of&nbsp;each group, as what we are doing now.&nbsp; This =
however is=20
  neither efficient nor elegant.</P>
  <P>Any suggestion/recommendation would be greatly appreciated.</P>
  <P>Thanks</P>
  <P>Ryan Koh</P>
  <P>
  <P><BR>
  <HR SIZE=3D1>
  <A=20
  =
href=3D"http://uk.yahoo.com/mail/tagline_xtra/?http://uk.docs.yahoo.com/m=
ail_storage.html"><B><FONT=20
  face=3DArial size=3D2>With Yahoo! Mail you can get a bigger mailbox -- =
choose a=20
  size that fits your =
needs</FONT></B></A><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0009_01C2C19E.C70321E0--

Date: Wed, 22 Jan 2003 06:02:31 +0000 (GMT)
From: =?iso-8859-1?q?Ryan=20Koh?= <[email-masked]>
Subject: Multiple symmetric algo-encrypted data in single S/MIME message
To: [email-masked]
Sender: [email-masked]

--0-1176889413-1043215351=:62897
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi

My organisation users need to communicate with 2 groups of users, on different S/MIME secure mail systems.  The problem lies in them using different symmetric algorithms for data encryption.  I am assessing possibility of building a single mail client to compose and send S/MIME messages to selected users on both nets, at the same time (i.e. at one sending operation).  This means that there would logically be 2 sets of encrypted blobs in the S/MIME message sent out, but I am not sure if this is supported in S/MIME format.

The easy way out of course is to send out the same mails twice separately, to users of each group, as what we are doing now.  This however is neither efficient nor elegant.

Any suggestion/recommendation would be greatly appreciated.

Thanks

Ryan Koh

---------------------------------
With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs

--0-1176889413-1043215351=:62897
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<P>Hi</P>
<P>My organisation users need to communicate with 2 groups of users, on different S/MIME secure mail systems.&nbsp; The problem lies in them using different symmetric&nbsp;algorithms for data encryption.&nbsp; I am assessing possibility of building a single mail client to compose and send S/MIME messages to selected users on both nets, at the same time (i.e. at one sending operation).&nbsp; This means that there would logically be 2 sets of encrypted blobs in the S/MIME message sent out, but I am not sure if this is supported in S/MIME format.</P>
<P>The easy way out of course is to send out the same mails twice separately, to users of&nbsp;each group, as what we are doing now.&nbsp; This however is neither efficient nor elegant.</P>
<P>Any suggestion/recommendation would be greatly appreciated.</P>
<P>Thanks</P>
<P>Ryan Koh</P><p><p><br><hr size=1><a href="http://uk.yahoo.com/mail/tagline_xtra/?http://uk.docs.yahoo.com/mail_storage.html"><b><font face="Arial" size="2">With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs</font></b></a><br>
--0-1176889413-1043215351=:62897--

Date: Mon, 20 Jan 2003 14:42:15 -0500
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: draft-ietf-smime-aes-alg-06.txt
Cc: [email-masked]
Sender: [email-masked]

The S/MIME WG is finished with this document, and we believe that it is 
ready for IETF-wide Last Call and subsequent publication as a 
standards-track RFC.

	Title		: Use of the AES Encryption Algorithm in CMS
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-aes-alg-06.txt
	Pages		: 12
	Date		: 2003-1-17
	
     This document specifies the conventions for using the Advanced
    Encryption Standard (AES) algorithm [AES] for encryption with the
    Cryptographic Message Syntax (CMS) [CMS].

    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-06.txt

Thanks,
   Russ

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-aes-alg-06.txt
Date: Mon, 20 Jan 2003 07:48:00 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Use of the AES Encryption Algorithm in CMS
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-aes-alg-06.txt
	Pages		: 12
	Date		: 2003-1-17
	
This document specifies the conventions for using the Advanced 
Encryption Standard (AES) algorithm [AES] for encryption with the 
Cryptographic Message Syntax (CMS) [CMS].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-aes-alg-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-aes-alg-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-aes-alg-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc2633bis-03.txt
Date: Fri, 17 Jan 2003 07:23:35 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: S/MIME Version 3.1 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2633bis-03.txt
	Pages		: 0
	Date		: 2003-1-16
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and data confidentiality (using encryption).

S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME
takes advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems.

Further, S/MIME can be used in automated message transfer agents that
use cryptographic security services that do not require any human
intervention, such as the signing of software-generated documents and
the encryption of FAX messages sent over the Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2633bis-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-rfc2633bis-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc2633bis-03.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 15 Jan 2003 10:56:41 -0500
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-symkeydist-09.txt
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
All,<br>
<br>
The changes to this draft were making transactionId, senderNonce, and recipientNonce
mandtory for origination and reception by the GLA. &nbsp;CMC and this spec both
said they had to be returned if included in a request by the server, which
makes them mandatory. &nbsp;This just wasn't reflected in the attribute conformance
table.<br>
<br>
spt<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> wrote:<br>
<blockquote type="cite" cite="[email-masked]">
  <pre wrap="">A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: CMS Symmetric Key Management and Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-09.txt
	Pages		: 81
	Date		: 2003-1-14
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

A URL for this Internet-Draft is:
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-09.txt">http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-09.txt</a>

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-symkeydist-09.txt".

A list of Internet-Drafts directories can be found in
<a class="moz-txt-link-freetext" href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a> 
or <a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a>

Internet-Drafts can also be obtained by e-mail.

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
  </pre>
</blockquote>
<br>
</body>
</html>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-symkeydist-09.txt
Date: Wed, 15 Jan 2003 07:58:53 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: CMS Symmetric Key Management and Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-09.txt
	Pages		: 81
	Date		: 2003-1-14
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-09.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-symkeydist-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-symkeydist-09.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 10 Jan 2003 14:11:40 -0500
To: Elanor Foley <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Multiple signers and changing receipt requests
Sender: [email-masked]

Elanor:

First, I want to point out that RFC 2630 has been superceded by RFC 3369.

>As I understand CMS rfc2630 and ESS rfc2634, it is possible to create a
>SignedData with multiple signers (one signedData with multiple signerInfos).
>Say one of these signers has included a ReceiptRequest in his
>signedAttributes. How would another (subsequent) signer also add a
>ReceiptRequest or modify the existing one? It looks like there is no
>provision for this. The first signer to request a receipt pre-empts any
>other signer who may wish a different receipt request. The receipt request
>itself cannot be modified because it is a signed attribute. Can subsequent
>signers pretend to be an MLAgent and add a mlReceiptPolicy?

A subsequent signer cannot (and should not be able to) make any change to 
the information covered by the first signer.  So, more information is 
needed to understand the context of your question.  By reading between the 
lines, it appears that all of the signatures are not equal in your 
application.  That being the case, you might consider countersignatures or 
further nesting (SignedData encapsulating another SignedData).

>Also, I find myself confused by statements in sections 2.2.1 and 2.3 from
>the ESS rfc. These are highlighted by asterisks below
>ESS 2.1 Signed Receipt Concepts
>
>The originator of a message may request a signed receipt from the
>message's recipients.
>ESS 2.2 Receipt Request Creation
>
><snip>
>Only one receiptRequest attribute can be included in the
>signedAttributes of a SignerInfo.
>ESS 2.2.1 Multiple Receipt Requests
>
>There can be multiple SignerInfos within a SignedData object, and
>each SignerInfo may include signedAttributes. Therefore, a single
>SignedData object may include multiple SignerInfos, each SignerInfo
>having a receiptRequest attribute. For example, an originator can
>send a signed message with two SignerInfos, one containing a DSS
>signature, the other containing an RSA signature.
>
>Each recipient SHOULD return only one signed receipt.
>
>/***Not all of the SignerInfos need to include receipt requests, but in
>all of the SignerInfos that do contain receipt requests, the receipt
>requests MUST be identical.***/

This is because clients are expected to process one signerInfo, not all of 
them.

>But
>ESS 2.3 Receipt Request Processing
>
>A receiptRequest is associated only with the SignerInfo object to
>which the receipt request attribute is directly attached. Receiving
>software SHOULD examine the signedAttributes field of each of the
>SignerInfos for which it verifies a signature in the innermost
>signedData object to determine if a receipt is requested. /***This may
>result in the receiving agent processing multiple receiptRequest
>attributes included in a single SignedData object, such as requests
>made from different people who signed the object in parallel.***/
>The "different people" are not making different requests? They're just
>copying the first person's receipt request?

You are right this should not happen.  The receipt requests MUST be identical.

Russ

From: Elanor Foley <[email-masked]>
To: [email-masked]
Subject: Multiple signers and changing receipt requests
Date: Tue, 7 Jan 2003 16:52:02 -0000 
Sender: [email-masked]

Hello, 
As I understand CMS rfc2630 and ESS rfc2634, it is possible to create a
SignedData with multiple signers (one signedData with multiple signerInfos).
Say one of these signers has included a ReceiptRequest in his
signedAttributes. How would another (subsequent) signer also add a
ReceiptRequest or modify the existing one? It looks like there is no
provision for this. The first signer to request a receipt pre-empts any
other signer who may wish a different receipt request. The receipt request
itself cannot be modified because it is a signed attribute. Can subsequent
signers pretend to be an MLAgent and add a mlReceiptPolicy? 
Also, I find myself confused by statements in sections 2.2.1 and 2.3 from
the ESS rfc. These are highlighted by asterisks below 
ESS 2.1 Signed Receipt Concepts

The originator of a message may request a signed receipt from the
message's recipients. 
ESS 2.2 Receipt Request Creation

<snip> 
Only one receiptRequest attribute can be included in the
signedAttributes of a SignerInfo.
ESS 2.2.1 Multiple Receipt Requests

There can be multiple SignerInfos within a SignedData object, and
each SignerInfo may include signedAttributes. Therefore, a single
SignedData object may include multiple SignerInfos, each SignerInfo
having a receiptRequest attribute. For example, an originator can
send a signed message with two SignerInfos, one containing a DSS
signature, the other containing an RSA signature.

Each recipient SHOULD return only one signed receipt.

/***Not all of the SignerInfos need to include receipt requests, but in
all of the SignerInfos that do contain receipt requests, the receipt
requests MUST be identical.***/ 
But 
ESS 2.3 Receipt Request Processing

A receiptRequest is associated only with the SignerInfo object to
which the receipt request attribute is directly attached. Receiving
software SHOULD examine the signedAttributes field of each of the
SignerInfos for which it verifies a signature in the innermost
signedData object to determine if a receipt is requested. /***This may
result in the receiving agent processing multiple receiptRequest
attributes included in a single SignedData object, such as requests
made from different people who signed the object in parallel.***/
The "different people" are not making different requests? They're just
copying the first person's receipt request? 
Thanks for your help, 
- Lnr
____________________________________________ 
Lnr Foley 
Baltimore Technologies
Web: <http://www.baltimore.com/> 
_____________________________________________ 

-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com

From: Elanor Foley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Recall: Multiple signers and changing receipt requests
Date: Tue, 7 Jan 2003 16:41:09 -0000 
Expiry-Date: Thu, 9 Jan 2003 16:48:46 -0000
Sender: [email-masked]

Elanor Foley would like to recall the message, "Multiple signers and
changing receipt requests".

-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com

From: Elanor Foley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Multiple signers and changing receipt requests
Date: Tue, 7 Jan 2003 16:38:58 -0000 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2B66B.469745B0
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,
 
As I understand CMS rfc2630 and ESS rfc2634, it is possible to create a
SignedData with multiple signers (one signedData with multiple signerInfos).
Say one of these signers has included a ReceiptRequest in his
signedAttributes. How would another (subsequent) signer also add a
ReceiptRequest or modify the existing one? It looks like there is no
provision for this. The first signer to request a receipt pre-empts any
other signer who may wish a different receipt request. The receipt request
itself cannot be modified because it is a signed attribute. Can subsequent
signers pretend to be an MLAgent and add a mlReceiptPolicy?
 
Also, I find myself confused by statements in sections 2.2.1 and 2.3 from
the ESS rfc. These are highlighted by asterisks below
ESS 2.1 Signed Receipt Concepts

   The originator of a message may request a signed receipt from the
   message's recipients. 
 
ESS 2.2 Receipt Request Creation

   <snip>
Only one receiptRequest attribute can be included in the
   signedAttributes of a SignerInfo.

ESS 2.2.1 Multiple Receipt Requests

   There can be multiple SignerInfos within a SignedData object, and
   each SignerInfo may include signedAttributes. Therefore, a single
   SignedData object may include multiple SignerInfos, each SignerInfo
   having a receiptRequest attribute. For example, an originator can
   send a signed message with two SignerInfos, one containing a DSS
   signature, the other containing an RSA signature.

   Each recipient SHOULD return only one signed receipt.

   /***Not all of the SignerInfos need to include receipt requests, but in
   all of the SignerInfos that do contain receipt requests, the receipt
   requests MUST be identical.***/

But
 
ESS 2.3 Receipt Request Processing

   A receiptRequest is associated only with the SignerInfo object to
   which the receipt request attribute is directly attached. Receiving
   software SHOULD examine the signedAttributes field of each of the
   SignerInfos for which it verifies a signature in the innermost
   signedData object to determine if a receipt is requested. /***This may
   result in the receiving agent processing multiple receiptRequest
   attributes included in a single SignedData object, such as requests
   made from different people who signed the object in parallel.***/

The "different people" are not making different requests? They're just
copying the first person's receipt request?
 
Thanks for your help,
 -    Lnr

____________________________________________ 
Lnr Foley 
Baltimore Technologies
Web:  <http://www.baltimore.com/> http://www.baltimore.com 
_____________________________________________ 

 

------_=_NextPart_001_01C2B66B.469745B0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>

<META content="MSHTML 6.00.2800.1106" name=GENERATOR></HEAD>
<BODY>
<DIV><CODE><FONT size=3><FONT face=Arial color=#0000ff size=2><SPAN 
class=320594115-07012003>Hello,</SPAN></FONT></FONT></CODE></DIV>
<DIV><CODE><FONT size=3><FONT face=Arial color=#0000ff size=2><SPAN 
class=320594115-07012003></SPAN></FONT></FONT></CODE>&nbsp;</DIV>
<DIV><CODE><FONT face=Arial color=#0000ff size=2><SPAN 
class=320594115-07012003>As I understand CMS rfc2630 and ESS rfc2634, it is 
possible to create a SignedData with multiple signers (one signedData with 
multiple signerInfos). Say one of these signers has included a ReceiptRequest in 
his signedAttributes. How would another (subsequent) signer also add a 
ReceiptRequest<SPAN class=787233516-07012003> or modify the existing one</SPAN>? 
It looks like there is no provision for this. The first signer to request a 
receipt pre-empts any other signer who may wish a different receipt 
request.<SPAN class=787233516-07012003>&nbsp;The receipt request itself cannot 
be modified because it is a signed attribute.&nbsp;</SPAN>Can&nbsp;subsequent 
signers&nbsp;pretend to be an MLAgent and add a <FONT 
color=#000000>mlReceiptPolicy</FONT>?</SPAN></FONT></CODE></DIV>
<DIV><CODE><FONT size=3><FONT face=Arial color=#0000ff size=2><SPAN 
class=320594115-07012003></SPAN></FONT></FONT></CODE>&nbsp;</DIV>
<DIV><CODE><FONT size=3><FONT face=Arial color=#0000ff size=2><SPAN 
class=320594115-07012003>Also, I find myself confused by statements in sections 
2.2.1 and 2.3 from the ESS rfc. These are highlighted by asterisks 
below</SPAN></FONT></FONT></CODE></DIV>
<DIV>
<DIV><CODE><FONT size=3><FONT face=Arial color=#0000ff size=2><SPAN 
class=320594115-07012003></SPAN></FONT></FONT></CODE></DIV><CODE><FONT 
size=3><FONT face=Arial color=#0000ff size=2><SPAN 
class=320594115-07012003></SPAN></FONT></FONT></CODE></DIV>
<DIV><CODE><FONT face=Arial><SPAN class=320594115-07012003>ESS 2.1 Signed 
Receipt Concepts<BR><BR>&nbsp;&nbsp; The originator of a message may request a 
signed receipt from the<BR>&nbsp;&nbsp; message's recipients. 
</SPAN></FONT></CODE></DIV>
<DIV><CODE><FONT face=Arial><SPAN 
class=320594115-07012003></SPAN></FONT></CODE>&nbsp;</DIV>
<DIV><CODE><FONT face=Arial><SPAN class=320594115-07012003>ESS 2.2 Receipt 
Request Creation<BR><BR>&nbsp;&nbsp; &lt;snip&gt;</SPAN></FONT></CODE></DIV>
<DIV><CODE><FONT face=Arial><SPAN class=320594115-07012003>Only one 
receiptRequest attribute can be included in the<BR>&nbsp;&nbsp; signedAttributes 
of a SignerInfo.<BR></DIV></SPAN></FONT></CODE>
<DIV><CODE><FONT face=Arial><SPAN class=320594115-07012003>ESS 2.2.1 Multiple 
Receipt Requests<BR><BR>&nbsp;&nbsp; There can be multiple SignerInfos within a 
SignedData object, and<BR>&nbsp;&nbsp; each SignerInfo may include 
signedAttributes. Therefore, a single<BR>&nbsp;&nbsp; SignedData object may 
include multiple SignerInfos, each SignerInfo<BR>&nbsp;&nbsp; having a 
receiptRequest attribute. For example, an originator can<BR>&nbsp;&nbsp; send a 
signed message with two SignerInfos, one containing a DSS<BR>&nbsp;&nbsp; 
signature, the other containing an RSA signature.<BR><BR>&nbsp;&nbsp; Each 
recipient SHOULD return only one signed receipt.<BR><BR>&nbsp;&nbsp; /***Not all 
of the SignerInfos need to include receipt requests, but in<BR>&nbsp;&nbsp; all 
of the SignerInfos that do contain receipt requests, the receipt<BR>&nbsp;&nbsp; 
requests MUST be identical.***/</SPAN></FONT></CODE></DIV>
<DIV><CODE><FONT face=Arial><SPAN 
class=320594115-07012003></SPAN></FONT></CODE>&nbsp;</DIV>
<DIV><CODE><FONT size=+0><SPAN class=320594115-07012003><FONT color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV><SPAN class=320594115-07012003></SPAN><FONT face=Arial><FONT 
color=#0000ff><FONT size=2>B<SPAN 
class=320594115-07012003>ut</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=320594115-07012003></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><FONT face="Courier New"><SPAN 
class=320594115-07012003>ESS 2.3 Receipt Request Processing<BR><BR>&nbsp;&nbsp; 
A receiptRequest is associated only with the SignerInfo object 
to<BR>&nbsp;&nbsp; which the receipt request attribute is directly attached. 
Receiving<BR>&nbsp;&nbsp; software SHOULD examine the signedAttributes field of 
each of the<BR>&nbsp;&nbsp; SignerInfos for which it verifies a signature in the 
innermost<BR>&nbsp;&nbsp; signedData object to determine if a receipt is 
requested. <FONT color=#ff0000><FONT color=#000000>/***This may<BR>&nbsp;&nbsp; 
result in the receiving agent processing multiple receiptRequest<BR>&nbsp;&nbsp; 
attributes included in a single SignedData object, such as 
requests<BR>&nbsp;&nbsp; made from different people who signed the object in 
parallel.***/</FONT><BR></FONT></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff size=2></FONT><FONT color=#0000ff size=2></FONT><FONT 
color=#0000ff size=2></FONT><BR></DIV></FONT></SPAN></FONT></CODE>
<DIV><CODE><FONT size=3><FONT face=Arial color=#0000ff size=2><SPAN 
class=320594115-07012003><SPAN class=787233516-07012003>The "different people" 
are not making different requests? They're just copying the first person's 
receipt request?</SPAN></SPAN></FONT></FONT></CODE></DIV>
<DIV><CODE><FONT size=3><FONT face=Arial color=#0000ff size=2><SPAN 
class=320594115-07012003><SPAN 
class=787233516-07012003></SPAN></SPAN></FONT></FONT></CODE>&nbsp;</DIV>
<DIV><CODE><FONT size=3><FONT><SPAN class=320594115-07012003><SPAN 
class=787233516-07012003>
<DIV><CODE><FONT face=Arial color=#0000ff size=2><SPAN 
class=320594115-07012003><SPAN class=787233516-07012003>Thanks for your 
help,</SPAN></SPAN></FONT></CODE></DIV>
<DIV><CODE><FONT><SPAN class=320594115-07012003><FONT face=Arial><FONT 
color=#0000ff><FONT size=2><SPAN class=787233516-07012003>&nbsp;- 
&nbsp;</SPAN><SPAN class=787233516-07012003>&nbsp;</SPAN> 
Lnr<BR></FONT></FONT></FONT><SPAN class=787233516-07012003>
<P><FONT color=#0000ff><FONT face=Arial 
size=2>____________________________________________ <BR>Lnr 
Foley&nbsp;<BR>Baltimore Technologies<BR>Web: </FONT><A 
href="http://www.baltimore.com/" target=_blank><FONT face=Arial 
size=2>http://www.baltimore.com</FONT></A><FONT face=Arial size=2> 
<BR>_____________________________________________ </FONT></FONT></P><BR><FONT 
face=Arial color=#0000ff 
size=2>&nbsp;</FONT></SPAN></SPAN></FONT></CODE></DIV></SPAN></SPAN></FONT></DIV></FONT></CODE></BODY></HTML>

------_=_NextPart_001_01C2B66B.469745B0--