Re: Protecting fields via message/rfc822 and merging issues

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

Some clients are still better at reply quoting than others -- sorry about
the mess.  Comments inline marked with [bcr].

----- Original Message -----
From: "Bonatti, Chris" <[e-mail]>
To: "IETF SMIME WG" <[e-mail]>
Sent: Thursday, April 25, 2002 9:30 AM
Subject: Protecting fields via message/rfc822 and merging issues


>   The first part of the solution seems like a done deal.  I would note
that we should be able to omit the "orig-date" and "from" fields (required
by RFC 2822) from the inner message if we use the message/partial type vs
message/rfc822 in the protected MIME object.  However, I think it would be
wise if we simply allowed either type in this case.  I think that support
for message/rfc822 is widespread, perhaps almost universal.  However, the
level of support for message/partial is unknown (to me anyway).  Also, use
of message/partial in this way isn't *exactly* for the reasons that RFC2046
describes its use.  Since Ned suggested it, I would guess he thinks it is,
though.

[bcr] One way to think about message/partial is that this header privacy
issue represents a new S/MIME idiom, and thus you need to write a bunch of
code anyway to handle it.  The argument against message/partial would be
that applications are using a separate MIME library which would choke on
message/partial if it didn't already support it, and older clients that are
unaware of this use might fail completely to process the message.  I would
be more in favor of exploring message/rfc822, since I'm fairly certain that
most GUI implementations just pop up a new message window.  This has the
added benefit of automatically providing compartementalization of the
protected headers, since those will be attributes of the new window.

>    b) Discarding the outer 822 message and looking only at the
> inner fields works provided that the inner message is
> complete.  However, it does not work if only a partial
> list of fields is included in the inner message.  Also,
> since we negate the usefulness of the outer message in
> all cases, we strongly encourage that it be a blank
> "dummy" message.  This would effectively require the
> application to do security processing even to display
> the originator, subject line, etc. -- fields normally
> shown in a mailbox view.  Blake also correctly pointed
> out that this would squash useful headers like "trace"
> (i.e., Received:...) and things added by list exploders.

[bcr] Right, and I think this also includes header security policies (not
necessarily cryptography, but generic rewriting) applied by the organization
such as rewritten address lines for host name hiding or adding disclosed
recipients.  I think this is where we start running into a problem, and
where we're in danger of failing.

>   Of these, I think I favor (c).  However, regardless of which option we
choose, we should say something about using dummy values of the "orig-date"
and "from" fields in the event that the originator wants to protect the
confidentiality of that information.  Since these elements are required in
an 822 message, some dummy value MUST be provided in the outer message.  I
don't think we need to necessarily specify what these values should be, but
we should say something about the need for them.

[bcr] I agree -- I think this is going to be part of any work that we
pursue.

>   Obviously, my belief is that (d) is the only one that works.  However,
I'm not happy with how it works in the encrypted-only case.  I'm also
somewhat sensitive to "attribute bloat".  I therefore earnestly hope
somebody else sees something that I've missed.

[bcr] I think that the biggest problem I'm having is that we're trying to
mix authenticated / unauthenticated / encrypted / unencrypted headers
together and try to do the right thing in an automated fashion.  As much as
as we might like to define this, I think the only option might be to take
the coward's way out and explain that the presentation and merging of the
headers are the problem of the client, and that it's not possible to
automatically mix them.  The realization that I'm coming to is that there is
no utility in merging the headers, and we shouldn't even attempt it, and we
should document that the client needs to potentially make decisions about
how much to trust the internal headers vs. the external headers, and it is
their responsibility to demonstrate the separation.

[bcr] My thinking right now is along the lines of the following, and I could
very well be missing some important issues:

1. Use message/rfc822 with a full set of headers for the inner protected
content.  This is backward compatible, and it's entirely possible that
existing clients might even process this correctly.

2. Define placebo values for any outer message required fields.

3. Explain the client considerations for presentation.

Blake




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3U6dsU28542 for ietf-smime-bks; Mon, 29 Apr 2002 23:39:54 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3U6dqa28530 for <[e-mail]>; Mon, 29 Apr 2002 23:39:52 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Mon, 29 Apr 2002 23:39:49 -0700
Message-ID: <0c0901c1f011$8131cf40$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "Bonatti, Chris" <[e-mail]>, "IETF SMIME WG" <[e-mail]>
References: <[e-mail]>
Subject: Re: Protecting fields via message/rfc822 and merging issues
Date: Mon, 29 Apr 2002 23:37:31 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some clients are still better at reply quoting than others -- sorry about
the mess.  Comments inline marked with [bcr].

----- Original Message -----
From: "Bonatti, Chris" <[e-mail]>
To: "IETF SMIME WG" <[e-mail]>
Sent: Thursday, April 25, 2002 9:30 AM
Subject: Protecting fields via message/rfc822 and merging issues


>   The first part of the solution seems like a done deal.  I would note
that we should be able to omit the "orig-date" and "from" fields (required
by RFC 2822) from the inner message if we use the message/partial type vs
message/rfc822 in the protected MIME object.  However, I think it would be
wise if we simply allowed either type in this case.  I think that support
for message/rfc822 is widespread, perhaps almost universal.  However, the
level of support for message/partial is unknown (to me anyway).  Also, use
of message/partial in this way isn't *exactly* for the reasons that RFC2046
describes its use.  Since Ned suggested it, I would guess he thinks it is,
though.

[bcr] One way to think about message/partial is that this header privacy
issue represents a new S/MIME idiom, and thus you need to write a bunch of
code anyway to handle it.  The argument against message/partial would be
that applications are using a separate MIME library which would choke on
message/partial if it didn't already support it, and older clients that are
unaware of this use might fail completely to process the message.  I would
be more in favor of exploring message/rfc822, since I'm fairly certain that
most GUI implementations just pop up a new message window.  This has the
added benefit of automatically providing compartementalization of the
protected headers, since those will be attributes of the new window.

>    b) Discarding the outer 822 message and looking only at the
> inner fields works provided that the inner message is
> complete.  However, it does not work if only a partial
> list of fields is included in the inner message.  Also,
> since we negate the usefulness of the outer message in
> all cases, we strongly encourage that it be a blank
> "dummy" message.  This would effectively require the
> application to do security processing even to display
> the originator, subject line, etc. -- fields normally
> shown in a mailbox view.  Blake also correctly pointed
> out that this would squash useful headers like "trace"
> (i.e., Received:...) and things added by list exploders.

[bcr] Right, and I think this also includes header security policies (not
necessarily cryptography, but generic rewriting) applied by the organization
such as rewritten address lines for host name hiding or adding disclosed
recipients.  I think this is where we start running into a problem, and
where we're in danger of failing.

>   Of these, I think I favor (c).  However, regardless of which option we
choose, we should say something about using dummy values of the "orig-date"
and "from" fields in the event that the originator wants to protect the
confidentiality of that information.  Since these elements are required in
an 822 message, some dummy value MUST be provided in the outer message.  I
don't think we need to necessarily specify what these values should be, but
we should say something about the need for them.

[bcr] I agree -- I think this is going to be part of any work that we
pursue.

>   Obviously, my belief is that (d) is the only one that works.  However,
I'm not happy with how it works in the encrypted-only case.  I'm also
somewhat sensitive to "attribute bloat".  I therefore earnestly hope
somebody else sees something that I've missed.

[bcr] I think that the biggest problem I'm having is that we're trying to
mix authenticated / unauthenticated / encrypted / unencrypted headers
together and try to do the right thing in an automated fashion.  As much as
as we might like to define this, I think the only option might be to take
the coward's way out and explain that the presentation and merging of the
headers are the problem of the client, and that it's not possible to
automatically mix them.  The realization that I'm coming to is that there is
no utility in merging the headers, and we shouldn't even attempt it, and we
should document that the client needs to potentially make decisions about
how much to trust the internal headers vs. the external headers, and it is
their responsibility to demonstrate the separation.

[bcr] My thinking right now is along the lines of the following, and I could
very well be missing some important issues:

1. Use message/rfc822 with a full set of headers for the inner protected
content.  This is backward compatible, and it's entirely possible that
existing clients might even process this correctly.

2. Define placebo values for any outer message required fields.

3. Explain the client considerations for presentation.

Blake



Received: by above.proper.com (8.11.6/8.11.3) id g3QH2ER12123 for ietf-smime-bks; Fri, 26 Apr 2002 10:02:14 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QH2Ca12119 for <[e-mail]>; Fri, 26 Apr 2002 10:02:12 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Fri, 26 Apr 2002 10:01:48 -0700
Message-ID: <087501c1ed43$1f0641a0$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "Bonatti, Chris" <[e-mail]>, "Housley, Russ" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Compression within RFC2633bis?
Date: Fri, 26 Apr 2002 09:55:08 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: "Bonatti, Chris" <[e-mail]>
To: "Blake Ramsdell" <[e-mail]>; "Housley, Russ"
<[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Friday, April 26, 2002 6:04 AM
Subject: RE: Compression within RFC2633bis?


> > > Yes.  I think that RFC2633bis out to say that compression MAY be
applied
> > > before encryption or signing.  It should probably indicate that
compression
> > > should only be applied once for a particular message.
> >
> > I think that an S/MIME capability should be used to negotiate this
> > beforehand, if we're going to head down this path.
> >
>
> My apologies for having nodded off on this thread, but why does this need
to be negotiated?  All the prior discussions of this revolved around what
the signer preferred.  So why can't it just be sender's choice?  The
encodings are unambiguous on reception.

I agree that it can be sender's choice.  I'd just make that choice based on
knowing that the recipient can receive it.

Blake



Received: by above.proper.com (8.11.6/8.11.3) id g3QD5Dg00688 for ietf-smime-bks; Fri, 26 Apr 2002 06:05:13 -0700 (PDT)
Received: from Obsidian (pcp833816pcs.nrockv01.md.comcast.net [68.50.112.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QD5Ca00682 for <[e-mail]>; Fri, 26 Apr 2002 06:05:12 -0700 (PDT)
Received: from [127.0.0.1] by Obsidian (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Fri, 26 Apr 2002 09:05:01 -0400
From: "Bonatti, Chris" <[e-mail]>
To: "Blake Ramsdell" <[e-mail]>, "Housley, Russ" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Compression within RFC2633bis?
Date: Fri, 26 Apr 2002 09:04:57 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <00dc01c1e71e$94749cf0$[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3QD5Ca00684
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Yes.  I think that RFC2633bis out to say that compression MAY be applied
> > before encryption or signing.  It should probably indicate that compression
> > should only be applied once for a particular message.
>
> I think that an S/MIME capability should be used to negotiate this
> beforehand, if we're going to head down this path.
>
> Blake

My apologies for having nodded off on this thread, but why does this need to be negotiated?  All the prior discussions of this revolved around what the signer preferred.  So why can't it just be sender's choice?  The encodings are unambiguous on reception.

I'll apologize in advance in case I've just got my 'stupid hat' on.

Chris





Received: by above.proper.com (8.11.6/8.11.3) id g3PHsDo04455 for ietf-smime-bks; Thu, 25 Apr 2002 10:54:13 -0700 (PDT)
Received: from Obsidian (pcp833816pcs.nrockv01.md.comcast.net [68.50.112.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PHsCa04451 for <[e-mail]>; Thu, 25 Apr 2002 10:54:12 -0700 (PDT)
Received: from [127.0.0.1] by Obsidian (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Thu, 25 Apr 2002 13:54:14 -0400
From: "Bonatti, Chris" <[e-mail]>
To: "IETF SMIME WG" <[e-mail]>
Subject: Proposed Text for X.400 Certificate Requirements
Date: Thu, 25 Apr 2002 13:54:13 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3PHsDa04452
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

  Another comment that I was handling coming out of the Minneapolis meeting was the need for text describing additional certificate requirements when using X400WRAP.  In considering the options, I think the best bet is add a single additional section under the existing certificate text to address the use of subjectAltName in certs, plus the requirements for sending and receiving S/MIME agents.  The required text is brief, and I think can be treated simply as requirements in addition to the CERT31 spec.

  One notable change from the treatment of this for SMTP is that we don't know for sure that the X.400 content we are protecting will contain an the originator's address.  All the ones I know about do, but I'm trying to avoid the black hole of trying to specify checking explicitly against every possible content type.  I'm therefore suggesting a more general statement that's conditional upon the presence of an originator address in the content.  I also recommend we therefore back the matching requirement down from a MUST to a SHOULD since there are conditions under which it maybe couldn't happen.

  The text I propose is shown below.  Comments are welcome.

Chris



=====================

Add the following to draft-ietf-smime-x400wrap-04:

4.3. Certificate Name Use for X.400 Content

End-entity certificates used in the context of this draft MAY contain an X.400 address as described in [X.400].  The address must be in the form of an "ORAddress".  The X.400 address SHOULD be in the subjectAltName extension, and SHOULD NOT be in the subject distinguished name.

Sending agents SHOULD make the originator address in the X.400 content (e.g., the "originator" field in P22) match an X.400 address in the signer's certificate. 

Receiving agents MUST recognize X.400 addresses in the subjectAltName field.

Receiving agents SHOULD check that the originator address in the X.400 content matches an X.400 address in the signer's certificate, if X.400 addresses are present in the certificate and an originator address is available in the content.  A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details.

The subject alternative name extension is used in S/MIME as the preferred means to convey the X.400 address(es) that correspond to the entity for this certificate. Any X.400 addresses present MUST be encoded using the x400Address CHOICE of the GeneralName type. Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple X.400 addresses MAY be present.

=====================




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PGUdl02241 for ietf-smime-bks; Thu, 25 Apr 2002 09:30:39 -0700 (PDT)
Received: from Obsidian (pcp833816pcs.nrockv01.md.comcast.net [68.50.112.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PGUba02237 for <[e-mail]>; Thu, 25 Apr 2002 09:30:38 -0700 (PDT)
Received: from [127.0.0.1] by Obsidian (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Thu, 25 Apr 2002 12:30:39 -0400
From: "Bonatti, Chris" <[e-mail]>
To: "IETF SMIME WG" <[e-mail]>
Subject: Protecting fields via message/rfc822 and merging issues
Date: Thu, 25 Apr 2002 12:30:38 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3PGUca02238
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

  I had an issue to resolve in draft-ietf-smime-x400wrap concerning the treatment of exterior SMTP header fields that are protected inside the X.400 content.  As Jim Craigie and Ned Freed pointed out back in January, this is virtually the same problem as the "leakage" problem that has been extensively discussed.  I have since bounced a few ideas off of Blake Ramsdell from the RFC2633bis perspective.

  From the prior leakage thread, part of the solution seems to be encapsulation of the message (complete with header fields) in the message/rfc822 type and using that as our MIME type to be protected.  Another part was the agreement of some rules for merging the inner and outer headers on reception.  Lastly, is was suggested that we need an indicator to signal that header merging is required.

  The first part of the solution seems like a done deal.  I would note that we should be able to omit the "orig-date" and "from" fields (required by RFC 2822) from the inner message if we use the message/partial type vs message/rfc822 in the protected MIME object.  However, I think it would be wise if we simply allowed either type in this case.  I think that support for message/rfc822 is widespread, perhaps almost universal.  However, the level of support for message/partial is unknown (to me anyway).  Also, use of message/partial in this way isn't *exactly* for the reasons that RFC2046 describes its use.  Since Ned suggested it, I would guess he thinks it is, though.

  I've given some thought to the second part of the solution, and have a initial take on how I think we should do the merging of headers.  The options are, as I see them:

   a)	Concatenating the contents of the inner fields to the 
	like-named outer fields is simple and works, but has the 
	disadvantage that any deliberately misleading information
	added to the outer headers will be merged with the 
	protected headers -- potentially leading the recipients 
	to believe that there were additional recipients, extra 
	routing hops, etc.  Also a different rule will still be 
	needed for single-valued fields such as subject, 
	message-id, orig-date, and Importance (from MIXER).
	If such a merge is used, then duplicate detection must 
	also be performed.  It would not be reasonable to 
	present the user with a list of recipients showing 
	each recipient twice in the case that the inner and 
	outer messages were identical.

   b)	Discarding the outer 822 message and looking only at the 
	inner fields works provided that the inner message is 
	complete.  However, it does not work if only a partial 
	list of fields is included in the inner message.  Also, 
	since we negate the usefulness of the outer message in 
	all cases, we strongly encourage that it be a blank 
	"dummy" message.  This would effectively require the 
	application to do security processing even to display 
	the originator, subject line, etc. -- fields normally 
	shown in a mailbox view.  Blake also correctly pointed 
	out that this would squash useful headers like "trace" 
	(i.e., Received:...) and things added by list exploders.

   c)	Replacing outer 822 field values with inner field values 
	when available provides is a simple and effective as (a), 
	but does not suffer the same disadvantage.  Unlike (b), 
	it allows a partial list of fields to be included in the 
	inner 822 message, consisting of only those fields the 
	originator wants to have protected.  It encourages 
	vendors to include a complete header in the outer 
	message, thus allowing efficient preliminary application 
	processing on receipt except where a field is 
	deliberately omitted for confidentiality purposes.  
	Blake pointed out to me that in this case, the rules 
	for merging might be much more complex.

  Of these, I think I favor (c).  However, regardless of which option we choose, we should say something about using dummy values of the "orig-date" and "from" fields in the event that the originator wants to protect the confidentiality of that information.  Since these elements are required in an 822 message, some dummy value MUST be provided in the outer message.  I don't think we need to necessarily specify what these values should be, but we should say something about the need for them.

  Regarding the third part of the problem, I think the options are pretty clear-cut but I am not happy with the answer.  The options as I see them are as follows:

12345678901234567890123456789012345678901234567890123456789012345

   a)	Add a signal in outer 822 message headers - This is bad
	because the signal itself can be modified affecting the 
	merging.

   b)	Add a signal in inner 822 message headers - This is bad
	because the signal is pointless.  You already know the 
	822 fields are there because you're already processing 
	them just to get the signal.

   c)	Add the same signal in the outer AND inner headers - This 
	doesn't really work any better than (a) because if the 
	outer indication is stripped, you don't know to look for 
	the inner one.

   d)	Include the signal in a CMS attribute - In a signed-only 
	or signed-and-encrypted message, the attribute should 
	probably be in the inner signedAttrs.  For encrypted-only 
	messages, it would have to go in the unprotectedAttrs, 
	but this is not optimal since it shares the disadvantages 
	of (a).  If this is the way forward, we have to have the 
	subsequent discussion of whether to use an existing or 
	new attribute.

  Obviously, my belief is that (d) is the only one that works.  However, I'm not happy with how it works in the encrypted-only case.  I'm also somewhat sensitive to "attribute bloat".  I therefore earnestly hope somebody else sees something that I've missed.

  Based on this line of thought, I would propose the following strawman additions to 2633bis (see below).  I think we'd also probably have to show some procedures or examples in section 3, but I did't want to go there until we collectively agree whether this is the right answer.  I've not yet come up with text for a "merging indicator" either.

Best regards,
Chris


=========================
Add to 2.4.1 or as a new 2.8:

In cases where protection of message headers is required, the protected message SHOULD be formatted according to [MSGFMT] including any headers that are to be protected.  The resulting message SHOULD comprise the innermost MIME data protected by CMS wrappers.  This inner message should be identified by one of the following MIME types:

 - message/rfc822

 - message/partial

Note that if message/rfc822 is used, [MSGFMT] requires that at least the "from" and "orig-date" fields be present in any such message.  If the originator does not wish to include these fields in the protected message, then message/partial SHOULD be used.

Under no circumstances shall the "trace" field be present in the inner message header.

The outer, unprotected header SHOULD generally omit any header fields that are otherwise included in the protected, inner message to prevent duplication.  However, the minimum requirements of [MSGFMT] MUST be satisfied.  Header fields that are protected only by a SignedData wrapper SHOULD be duplicated in the outer message header if they provide desired functionality (e.g., MDN processing, Subject, X-Priority).  Header fields that are protected by an EnvelopedData wrapper MUST NOT be included in the outer message header.  If confidentiality of required header fields is desired, then fields containing dummy values MUST be included in the outer message header.  The selection of appropriate dummy field values is a local implementation matter.

When displaying the received S/MIME message to a recipient, the headers of the inner and outer messages MUST be merged to provide the appearance of a homogeneous messaging service.  Any field present in the inner message header SHALL replace any instances of the like-named field in the outer message header.  The resulting merged header SHALL be displayed to the user when the S/MIME message is "opened".  The merged header does not need to be preserved in the stored message.

Note that it is acceptable to use only the outer message header to affect display properties of message that are considered to be unopened (i.e., in message summary screens, etc.).



Add to section B:

   [MSGFMT]       Resnick, P. "Internet Message Format", RFC 2822, April 2001.

===================




Received: by above.proper.com (8.11.6/8.11.3) id g3PETrg26088 for ietf-smime-bks; Thu, 25 Apr 2002 07:29:53 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3PETpa26083 for <[e-mail]>; Thu, 25 Apr 2002 07:29:51 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 25 Apr 2002 14:28:32 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA14153 for <[e-mail]>; Thu, 25 Apr 2002 10:28:19 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3PETjj21273 for <[e-mail]>; Thu, 25 Apr 2002 10:29:45 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1WTNT>; Thu, 25 Apr 2002 10:27:12 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.178]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1WTN2; Thu, 25 Apr 2002 10:26:57 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pradeep, PK" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
X-Priority: 1 (Highest)
Date: Thu, 25 Apr 2002 09:11:41 -0400
Subject: Re: Building SMIME and PKCS#7 objects
In-Reply-To: <[e-mail] iasw.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Pradeep:

Please see 
http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-07.txt.

Russ

At 12:42 PM 4/25/2002 +0530, Pradeep, PK wrote:
>Hi Group,
>
>We need to build and extract SMIME messages and PKCS#7 objects.
>
>We are exploring the possibility of building the same from the first
>principles using JAVA, using the core APIs provided by JAVA SDK1.4
>(latest) and J2EE.
>
>My first question is: Is it technically possible to accomplish the same?
>
>Let me just think aloud about how SMIME message can be created from the
>first principles and kindly let me know your comments if I am right or
>wrong:
>
>SMIME message is nothing but a text message with all the binary data
>base64 transfer encoded..
>
>The text message can be easily created by formulating the text in the
>format suggested by S/MIME specification.
>
>PKCS#7 object also nothing but a text message with binary content base64
>transfer encoded. certain portion of the PKCS#7 object is encrypted.
>
>I would highly appreciate if I can get examples of SMIME message and
>PKCS#7 object which somebody would have made..these examples can help us
>to make and authenticate whether our understanding of how these massages
>can be built is correct or not.
>
>
>Thank you,
>
>Warm Regards,
>
>Pradeep


Received: by above.proper.com (8.11.6/8.11.3) id g3P76Xv22232 for ietf-smime-bks; Thu, 25 Apr 2002 00:06:33 -0700 (PDT)
Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3P76Va22224 for <[e-mail]>; Thu, 25 Apr 2002 00:06:31 -0700 (PDT)
Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id B86943C14; Thu, 25 Apr 2002 02:06:22 -0500 (CDT)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 41529133E; Thu, 25 Apr 2002 00:06:18 -0700 (PDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <JR67ZQ31>; Thu, 25 Apr 2002 12:30:01 +0530
Message-ID: <[e-mail]>
From: "Pradeep, PK" <[e-mail]>
To: [e-mail]
Cc: "Housley, Russ" <[e-mail]>, Blake Ramsdell <[e-mail]>
Subject: Building SMIME and PKCS#7 objects
Date: Thu, 25 Apr 2002 12:42:51 +0530
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
content-class: urn:content-classes:message
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Group,

We need to build and extract SMIME messages and PKCS#7 objects.

We are exploring the possibility of building the same from the first
principles using JAVA, using the core APIs provided by JAVA SDK1.4
(latest) and J2EE.

My first question is: Is it technically possible to accomplish the same?

Let me just think aloud about how SMIME message can be created from the
first principles and kindly let me know your comments if I am right or
wrong:

SMIME message is nothing but a text message with all the binary data
base64 transfer encoded..

The text message can be easily created by formulating the text in the
format suggested by S/MIME specification.

PKCS#7 object also nothing but a text message with binary content base64
transfer encoded. certain portion of the PKCS#7 object is encrypted.

I would highly appreciate if I can get examples of SMIME message and
PKCS#7 object which somebody would have made..these examples can help us
to make and authenticate whether our understanding of how these massages
can be built is correct or not.


Thank you,

Warm Regards,

Pradeep


Received: by above.proper.com (8.11.6/8.11.3) id g3P18g200695 for ietf-smime-bks; Wed, 24 Apr 2002 18:08:42 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3P18Za00691 for <[e-mail]>; Wed, 24 Apr 2002 18:08:41 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Wed, 24 Apr 2002 18:08:23 -0700
Message-ID: <05ab01c1ebf4$623829c0$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "Pradeep, PK" <[e-mail]>, <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>
References: <[e-mail]>
Subject: Java S/MIME info (was Re: few more basic questions)
Date: Wed, 24 Apr 2002 17:58:59 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: "Pradeep, PK" <[e-mail]>
To: <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>
Sent: Monday, April 15, 2002 9:13 PM
Subject: few more basic questions


> Are there free APIs available in Java or Vb or both to
> 1) build S/MIME message
> 2) build PKCS#7 object to SignedData and Enveloped Data.

Try the Javamail third-party page for Java implementations.  This lists at
least three implementations that might still be around.

http://java.sun.com/products/javamail/Third_Party.html

Blake



Received: by above.proper.com (8.11.6/8.11.3) id g3OLaoe26360 for ietf-smime-bks; Wed, 24 Apr 2002 14:36:50 -0700 (PDT)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3OLama26355 for <[e-mail]>; Wed, 24 Apr 2002 14:36:48 -0700 (PDT)
Received: from checkpoint.local.aus.rsa.com by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Apr 2002 21:37:12 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id g3OLfYq03730 for <[e-mail]>; Thu, 25 Apr 2002 07:41:35 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <13VS18R3>; Thu, 25 Apr 2002 07:37:16 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.13]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1WMDB; Wed, 24 Apr 2002 17:34:08 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 24 Apr 2002 17:14:25 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: RE: Charter Update
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Is the WG consensus that RSA-OAEP, RSA-KEM, and AES should be in separate, 
independent documents.  This would allow AES to be used with any of the key 
management techniques?

Russ


Received: by above.proper.com (8.11.6/8.11.3) id g3O2isj25783 for ietf-smime-bks; Tue, 23 Apr 2002 19:44:54 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3O2iqa25779 for <[e-mail]>; Tue, 23 Apr 2002 19:44:52 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.2/8.12.2) with ESMTP id g3O2idK4013057; Wed, 24 Apr 2002 14:44:39 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA247723; Wed, 24 Apr 2002 14:44:37 +1200 (NZST) (sender [e-mail])
Date: Wed, 24 Apr 2002 14:44:37 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Charter Update
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert Zuccherato <[e-mail]> writes:

>But, it there is little support for OAEP, why replace it with a newer
>mechanism that has even less of an installed base?  It seems to me that there
>are fewer reasons for using KEM than there are for using OAEP.

Oh, you mean AES now *requires* KEM?  (I wasn't at Minneapolis either).  I
agree there, tying KEM to AES is just as bad as tying OAEP to it, for all the
reasons given during the debate some months ago.  Certainly a MAY is OK, but
the best place for it would appear to be in the CMS sundry-algorithms draft.

Peter.



Received: by above.proper.com (8.11.6/8.11.3) id g3MFBSa16911 for ietf-smime-bks; Mon, 22 Apr 2002 08:11:28 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MFBQa16907 for <[e-mail]>; Mon, 22 Apr 2002 08:11:26 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <JN5N5RZ3>; Mon, 22 Apr 2002 11:11:22 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Charter Update
Date: Mon, 22 Apr 2002 11:11:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EA0F.F5E921B0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1EA0F.F5E921B0
Content-Type: text/plain

> >Having not attended the Minneapolis meeting I must say that 
> I was very
> >surprised by your recommendation to drop OAEP as the MUST 
> implement key
> >transport mechanism with AES in favour of KEM.
> 
> This was done to death on the list a few months back.  The 
> consensus seemed to
> be that there was little support for OAEP, and a fair bit of 
> opposition to
> tying it to AES (see the list archives for the exact details 
> and rationale).

But, it there is little support for OAEP, why replace it with a newer
mechanism that has even less of an installed base?  It seems to me that
there are fewer reasons for using KEM than there are for using OAEP.

	Robert.

------_=_NextPart_001_01C1EA0F.F5E921B0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Charter Update</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; &gt;Having not attended the Minneapolis meeting =
I must say that </FONT>
<BR><FONT SIZE=3D2>&gt; I was very</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;surprised by your recommendation to drop =
OAEP as the MUST </FONT>
<BR><FONT SIZE=3D2>&gt; implement key</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;transport mechanism with AES in favour of =
KEM.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This was done to death on the list a few months =
back.&nbsp; The </FONT>
<BR><FONT SIZE=3D2>&gt; consensus seemed to</FONT>
<BR><FONT SIZE=3D2>&gt; be that there was little support for OAEP, and =
a fair bit of </FONT>
<BR><FONT SIZE=3D2>&gt; opposition to</FONT>
<BR><FONT SIZE=3D2>&gt; tying it to AES (see the list archives for the =
exact details </FONT>
<BR><FONT SIZE=3D2>&gt; and rationale).</FONT>
</P>

<P><FONT SIZE=3D2>But, it there is little support for OAEP, why replace =
it with a newer mechanism that has even less of an installed =
base?&nbsp; It seems to me that there are fewer reasons for using KEM =
than there are for using OAEP.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Robert.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1EA0F.F5E921B0--


Received: by above.proper.com (8.11.6/8.11.3) id g3MBN5E04307 for ietf-smime-bks; Mon, 22 Apr 2002 04:23:05 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MBN4a04302 for <[e-mail]>; Mon, 22 Apr 2002 04:23:05 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21629; Mon, 22 Apr 2002 07:23:02 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc2630bis-08.txt
Date: Mon, 22 Apr 2002 07:23:02 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-08.txt
	Pages		: 52
	Date		: 19-Apr-02
	
This document describes the Cryptographic Message Syntax (CMS).  This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2630bis-08.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-rfc2630bis-08.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-rfc2630bis-08.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc2630bis-08.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g3L5QuU27880 for ietf-smime-bks; Sat, 20 Apr 2002 22:26:56 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3L5Qs327876 for <[e-mail]>; Sat, 20 Apr 2002 22:26:54 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.2/8.12.2) with ESMTP id g3L5Qluc021626; Sun, 21 Apr 2002 17:26:47 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA72258; Sun, 21 Apr 2002 17:26:47 +1200 (NZST) (sender [e-mail])
Date: Sun, 21 Apr 2002 17:26:47 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Charter Update
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert Zuccherato <[e-mail]> writes:

>Having not attended the Minneapolis meeting I must say that I was very
>surprised by your recommendation to drop OAEP as the MUST implement key
>transport mechanism with AES in favour of KEM.

This was done to death on the list a few months back.  The consensus seemed to
be that there was little support for OAEP, and a fair bit of opposition to
tying it to AES (see the list archives for the exact details and rationale).

>Partly as a result of that effort, implementations of OAEP have started to
>appear (e.g. OpenSSL)

The OpenSSL OAEP had nothing to do with this, OAEP was added on an experimental
basis in late '98 or early '99 after the first PKCS #1v2 drafts appeared, and
it's stayed at that level ever since.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JEkaL24843 for ietf-smime-bks; Fri, 19 Apr 2002 07:46:36 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JEkYb24838 for <[e-mail]>; Fri, 19 Apr 2002 07:46:34 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <JH4VYCS1>; Fri, 19 Apr 2002 10:46:20 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, [e-mail]
Subject: RE: Charter Update
Date: Fri, 19 Apr 2002 10:46:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E7B0.F7C55690"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1E7B0.F7C55690
Content-Type: text/plain

Russ;

Having not attended the Minneapolis meeting I must say that I was very
surprised by your recommendation to drop OAEP as the MUST implement key
transport mechanism with AES in favour of KEM.  It wasn't all that long ago
that you were attempting to get everyone (S/MIME, TLS, X9.44) to agree on
requiring OAEP with AES as a method of transitioning to OAEP from PKCS#1
v1.5.  Partly as a result of that effort, implementations of OAEP have
started to appear (e.g. OpenSSL) and transitions to OAEP can actually now
start to occur.  If we are going to introduce a new MUST algorithm, and thus
additional uncertainty about what to use and how to transition, we really
should have a good reason.

In your presentation you say that KEM has better security proofs.  That may
be, however, OAEP is still secure.  No actual weaknesses in it have been
found.  On RSA's website there is a description of recent results on OAEP
that says "... it makes little sense replacing OAEP with a "more secure"
encoding method, because if a CCA2 adversary is able to break RSAEP-OAEP,
then she will be able to break RSAEP equipped with any encoding method (if
maybe slightly less efficiently)."
(http://www.rsasecurity.com/rsalabs/rsa_algorithm/oaep_security.html)  Thus,
there is no need to introduce KEM for security reasons.

Your presentation also lists some standards that already include KEM.
However, all of the ones that are listed except TLS also specify OAEP (ANSI
X9.44, IEEE P1363, ISO/IEC 18033-2, PKCS#1, S/MIME).  TLS, while it
specifies a variant of KEM, doesn't actually use anything that is compatible
with the KEM that S/MIME (and the other groups listed) would be using.  I
would also like to point out that XML Encryption has OAEP as a required key
transport method.  At this point it does seem like OAEP is starting to get
adopted by other groups and thus introducing KEM now seems to be
counterproductive.

It is true that with OAEP the message length is bounded.  However, for our
requirements here, is that really an issue?  

For these reasons I think we should reconsider your proposal to use RSA-KEM
instead of RSA-OAEP in draft-ietf-smime-aes-alg.


Robert Zuccherato
Entrust, Inc.


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Wednesday, April 17, 2002 4:57 PM
> To: [e-mail]
> Subject: Charter Update
> 
> 
> The S/MIME WG is very out of date.  I propose the attached 
> charter as a 
> replacement.
> 
> Note that I have assumed that the use of RSA OAEP key 
> management will be 
> published as a separate RFC (not combined with the AES draft).  The 
> rationale for this assumption is available in the 
> presentation that I gave 
> in Minneapolis.  The slides are on-line at 
> http://www.ietf.org/proceedings/02mar/slides/smime-1/index.html.
> 
> Please comment on the proposed charter.
> 
> Russ
> S/MIME WG Chair
> 
> 

------_=_NextPart_001_01C1E7B0.F7C55690
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Charter Update</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ;</FONT>
</P>

<P><FONT SIZE=3D2>Having not attended the Minneapolis meeting I must =
say that I was very surprised by your recommendation to drop OAEP as =
the MUST implement key transport mechanism with AES in favour of =
KEM.&nbsp; It wasn't all that long ago that you were attempting to get =
everyone (S/MIME, TLS, X9.44) to agree on requiring OAEP with AES as a =
method of transitioning to OAEP from PKCS#1 v1.5.&nbsp; Partly as a =
result of that effort, implementations of OAEP have started to appear =
(e.g. OpenSSL) and transitions to OAEP can actually now start to =
occur.&nbsp; If we are going to introduce a new MUST algorithm, and =
thus additional uncertainty about what to use and how to transition, we =
really should have a good reason.</FONT></P>

<P><FONT SIZE=3D2>In your presentation you say that KEM has better =
security proofs.&nbsp; That may be, however, OAEP is still =
secure.&nbsp; No actual weaknesses in it have been found.&nbsp; On =
RSA's website there is a description of recent results on OAEP that =
says &quot;... it makes little sense replacing OAEP with a &quot;more =
secure&quot; encoding method, because if a CCA2 adversary is able to =
break RSAEP-OAEP, then she will be able to break RSAEP equipped with =
any encoding method (if maybe slightly less efficiently).&quot;&nbsp; =
(<A =
HREF=3D"http://www.rsasecurity.com/rsalabs/rsa_algorithm/oaep_security.h=
tml" =
TARGET=3D"_blank">http://www.rsasecurity.com/rsalabs/rsa_algorithm/oaep_=
security.html</A>)&nbsp; Thus, there is no need to introduce KEM for =
security reasons.</FONT></P>

<P><FONT SIZE=3D2>Your presentation also lists some standards that =
already include KEM.&nbsp; However, all of the ones that are listed =
except TLS also specify OAEP (ANSI X9.44, IEEE P1363, ISO/IEC 18033-2, =
PKCS#1, S/MIME).&nbsp; TLS, while it specifies a variant of KEM, =
doesn't actually use anything that is compatible with the KEM that =
S/MIME (and the other groups listed) would be using.&nbsp; I would also =
like to point out that XML Encryption has OAEP as a required key =
transport method.&nbsp; At this point it does seem like OAEP is =
starting to get adopted by other groups and thus introducing KEM now =
seems to be counterproductive.</FONT></P>

<P><FONT SIZE=3D2>It is true that with OAEP the message length is =
bounded.&nbsp; However, for our requirements here, is that really an =
issue?&nbsp; </FONT></P>

<P><FONT SIZE=3D2>For these reasons I think we should reconsider your =
proposal to use RSA-KEM instead of RSA-OAEP in =
draft-ietf-smime-aes-alg.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Robert Zuccherato</FONT>
<BR><FONT SIZE=3D2>Entrust, Inc.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, April 17, 2002 4:57 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Charter Update</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The S/MIME WG is very out of date.&nbsp; I =
propose the attached </FONT>
<BR><FONT SIZE=3D2>&gt; charter as a </FONT>
<BR><FONT SIZE=3D2>&gt; replacement.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Note that I have assumed that the use of RSA =
OAEP key </FONT>
<BR><FONT SIZE=3D2>&gt; management will be </FONT>
<BR><FONT SIZE=3D2>&gt; published as a separate RFC (not combined with =
the AES draft).&nbsp; The </FONT>
<BR><FONT SIZE=3D2>&gt; rationale for this assumption is available in =
the </FONT>
<BR><FONT SIZE=3D2>&gt; presentation that I gave </FONT>
<BR><FONT SIZE=3D2>&gt; in Minneapolis.&nbsp; The slides are on-line at =
</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/proceedings/02mar/slides/smime-1/index.html"=
 =
TARGET=3D"_blank">http://www.ietf.org/proceedings/02mar/slides/smime-1/i=
ndex.html</A>.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please comment on the proposed charter.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Russ</FONT>
<BR><FONT SIZE=3D2>&gt; S/MIME WG Chair</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1E7B0.F7C55690--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JCs5B18077 for ietf-smime-bks; Fri, 19 Apr 2002 05:54:05 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3JCs3b18073 for <[e-mail]>; Fri, 19 Apr 2002 05:54:03 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Apr 2002 12:52:51 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA00901; Fri, 19 Apr 2002 08:52:36 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3JCs3211815; Fri, 19 Apr 2002 08:54:03 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX14NZ1>; Fri, 19 Apr 2002 08:51:33 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.63]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX14NZC; Fri, 19 Apr 2002 08:51:29 -0400
From: "Housley, Russ" <[e-mail]>
To: Blake Ramsdell <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 19 Apr 2002 08:53:12 -0400
Subject: Re: Compression within RFC2633bis?
In-Reply-To: <00dc01c1e71e$94749cf0$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake:

Good point.

Russ

At 02:18 PM 4/18/2002 -0700, Blake Ramsdell wrote:
>----- Original Message -----
>From: "Housley, Russ" <[e-mail]>
>To: <[e-mail]>
>Cc: <[e-mail]>; <[e-mail]>;
><[e-mail]>
>Sent: Thursday, April 18, 2002 1:37 PM
>Subject: Re: Compression within RFC2633bis?
>
>
> > Yes.  I think that RFC2633bis out to say that compression MAY be applied
> > before encryption or signing.  It should probably indicate that
>compression
> > should only be applied once for a particular message.
>
>I think that an S/MIME capability should be used to negotiate this
>beforehand, if we're going to head down this path.
>
>Blake


Received: by above.proper.com (8.11.6/8.11.3) id g3ILMO711166 for ietf-smime-bks; Thu, 18 Apr 2002 14:22:24 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3ILMN711162 for <[e-mail]>; Thu, 18 Apr 2002 14:22:23 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Thu, 18 Apr 2002 14:22:12 -0700
Message-ID: <00dc01c1e71e$94749cf0$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Compression within RFC2633bis?
Date: Thu, 18 Apr 2002 14:18:26 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: "Housley, Russ" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Thursday, April 18, 2002 1:37 PM
Subject: Re: Compression within RFC2633bis?


> Yes.  I think that RFC2633bis out to say that compression MAY be applied
> before encryption or signing.  It should probably indicate that
compression
> should only be applied once for a particular message.

I think that an S/MIME capability should be used to negotiate this
beforehand, if we're going to head down this path.

Blake



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3IKbcR07658 for ietf-smime-bks; Thu, 18 Apr 2002 13:37:38 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3IKba707653 for <[e-mail]>; Thu, 18 Apr 2002 13:37:36 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Apr 2002 20:36:26 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA13880; Thu, 18 Apr 2002 16:36:15 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3IKbfi08034; Thu, 18 Apr 2002 16:37:41 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX14HB4>; Thu, 18 Apr 2002 16:35:11 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.60]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX14HBP; Thu, 18 Apr 2002 16:35:05 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 18 Apr 2002 16:37:27 -0400
Subject: Re: Compression within RFC2633bis?
In-Reply-To: <[e-mail]. dnd.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Francois:

Yes.  I think that RFC2633bis out to say that compression MAY be applied 
before encryption or signing.  It should probably indicate that compression 
should only be applied once for a particular message.

Russ

At 04:15 PM 4/18/2002 -0400, [e-mail] wrote:
>Hi Blake and Russ,
>
>Since the IESG has approved the Internet-Draft "Compressed Data Content Type
>for S/MIME" <draft-ietf-smime-compression-07.txt> as a Proposed Standard,
>shouldn't it be referred as a MAY under the "S/MIME Version 3.1 Message
>Specification" <draft-ietf-smime-rfc2633bis-00.txt>?
>
>Please feel free to distribute your response to the S/MIME mailing list
>since I am not currently a member, but only occasionally monitor its
>content.
>
>Regards,
>
>Francois
>---------------------------------
>Francois Rousseau
>IT Standards, Senior Advisor - CSE
>Conseiller Superieur, Normes TI - CST
>[e-mail]
>[phone]
>Edward Drake Building
>1500 Bronson, Ottawa, Ontario, K1G 3Z4


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HL0oR03066 for ietf-smime-bks; Wed, 17 Apr 2002 14:00:50 -0700 (PDT)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HL0mm03059 for <[e-mail]>; Wed, 17 Apr 2002 14:00:48 -0700 (PDT)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.6/XCERT) with ESMTP id g3HL0hG07558 for <[e-mail]>; Wed, 17 Apr 2002 14:00:43 -0700 (PDT)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.6/XCERT) with ESMTP id g3HL0hT18901 for <[e-mail]>; Wed, 17 Apr 2002 14:00:43 -0700 (PDT)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <1D9H4540>; Wed, 17 Apr 2002 14:04:04 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.38]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1TXVY; Wed, 17 Apr 2002 16:56:38 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 17 Apr 2002 16:56:54 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Charter Update
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_31882134==_"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=====================_31882134==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

The S/MIME WG is very out of date.  I propose the attached charter as a 
replacement.

Note that I have assumed that the use of RSA OAEP key management will be 
published as a separate RFC (not combined with the AES draft).  The 
rationale for this assumption is available in the presentation that I gave 
in Minneapolis.  The slides are on-line at 
http://www.ietf.org/proceedings/02mar/slides/smime-1/index.html.

Please comment on the proposed charter.

Russ
S/MIME WG Chair


--=====================_31882134==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="Charter4.txt"


S/MIME Mail Security (smime)

Chair:
     Russ Housley <[e-mail]>

Security Area Director:
     Jeffrey Schiller <[e-mail]>
     Marcus Leech <[e-mail]>

Mailing Lists:
     General Discussion: [e-mail]
     To Subscribe:       [e-mail]
     Archive:            http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group has completed a series of Proposed  
Standards that comprise the S/MIME version 3 specification.   
Current efforts update and build upon these base specifications.

The Cryptographic Message Syntax (CMS) is cryptographic algorithm 
independent, yet there is always more than one way to use any 
algorithm.  To ensure interoperability, each algorithm should have
a specification that describes its use with CMS.  Specifications 
for the use of additional cryptographic algorithms will be 
developed.

As part of the specification update, a new suite of "mandatory 
to implement" algorithms will be selected.  These algorithms will
be reflected in updates to RFC 2632 and RFC 2633.

To aid implementers, documents containing example output for CMS
will be collected and published.  Some of the examples will include
structures and signed attributed defined in the Enhanced Security
Services (ESS) document.

In some situations it would be advantageous for the CMS RecipientInfo 
structure to support additional key management techniques, including 
cryptographic keys derived from passwords.  Also, a mechanism to 
facilitate the definition of additional key management techniques
will be defined.

Compressing data prior to encryption or signature has a number of 
advantages.  Compression improves security by removing known data 
patterns, improves throughput by reducing the amount of data which
needs to be encrypted or hashed, and reduces the overall message 
size.  Enabling S/MIME version 3 to use compression will provide 
all of these advantages.

S/MIME version 3 permits the use of previously distributed 
symmetric key-encryption keys.  Specifications for the distribution
of symmetric key-encryption keys to multiple message recipients 
will be developed.  Mail List Agents (MLAs) are one user of 
symmetric key-encryption keys.  The specification will be algorithm 
independent.

S/MIME version 3 supports security labels.  Specifications that show 
how this feature can be used to implement an organizational security 
policy will be developed.  Security policies from large organizations 
will be used as examples.

As part of S/MIME version 3, CMS is used to provide security 
to the message content.  CMS can also be employed in an X.400
electronic messaging envionments.  Specifications will be 
developed allowing this to be done in an interoperable manner.

Perform necessary interoperability testing to progress the S/MIME
version 3 specifications to Draft Standard.  Due to the dependency
of the CMS specification on the PKIX certificate and CRL profile,
the timeline for the actual progression is impossible to estimate.


Goals and Milestones:

History:
     Submit CMS compressed data content type a Proposed Standard.
     Submit security label usage specification as Informational RFC.
     Submit elliptic curve algorithm specification as Informational RFC.
     Submit mail list key distribution as a Proposed Standard.
     Submit update to RFC 2630 as a Proposed Standard.
     Submit AES key wrap algorithm description as Informational RFC.
     Last call on X.400 CMS wrapper specification.
     Last call on X.400 transport specification.
     Last call on HMAC key wrap description specification.
     First draft of CMS and ESS examples document.
     First draft of RSA OAEP algorithm specification.
     First draft of AES algorithm specification.
     First draft of update to RFC 2632.
     Frist draft of update to RFC 2633.

May 2002:
     Submit X.400 CMS wrapper specification as a Proposed Standard.
     Submit X.400 transport as a Proposed Standard.
     Submit HMAC key wrap description as an Informational RFC.

June 2002:
     Last call on CMS and ESS examples document.
     Last call on RSA OAEP algorithm specification.

July 2002:
     Last call on update to RFC 2632.
     Last call on update to RFC 2633.
     Last call on AES algorithm specification.

August 2002:
     Submit CMS and ESS examples document as Informational RFC.
     Submit RSA OAEP algorithm specification as Historical RFC.

October 2002:
     Sumbit update to RFC 2632 as Proposed Standard.
     Sumbit update to RFC 2633 as Proposed Standard.
     
December 2002:
     Sumbit AES algorithm specification as Proposed Standard.

--=====================_31882134==_--


Received: by above.proper.com (8.11.6/8.11.3) id g3H4VJE09074 for ietf-smime-bks; Tue, 16 Apr 2002 21:31:19 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3H4V5m09064 for <[e-mail]>; Tue, 16 Apr 2002 21:31:16 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.2/8.12.2) with ESMTP id g3H4UuMm011119; Wed, 17 Apr 2002 16:30:56 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA483732; Wed, 17 Apr 2002 16:30:55 +1200 (NZST) (sender [e-mail])
Date: Wed, 17 Apr 2002 16:30:55 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re:  few more basic questions
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Pradeep, PK" <[e-mail]> writes:

>Are there free APIs available in Java or Vb or both to
>1) build S/MIME message
>2) build PKCS#7 object to SignedData and Enveloped Data.

Finding something open-source which has Java and VB support (rather than C/C++)
is going to be tricky, because commercial VB and open-source crypto don't
really match up very well.  At the risk of posting advertising :-),
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ is available with both a VB
interface to the Windows DLL and as an ActiveX control.  There's also
Microsoft's clcom(?) control, which you can get from their web site somewhere.

(Disclaimer: I don't use VB or Java, so I don't have any direct experience with
             any of these).

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g3GK8No20217 for ietf-smime-bks; Tue, 16 Apr 2002 13:08:23 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3GK8Dm20206 for <[e-mail]>; Tue, 16 Apr 2002 13:08:21 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Apr 2002 20:07:06 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA17568 for <[e-mail]>; Tue, 16 Apr 2002 09:47:51 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3GDnCI09531 for <[e-mail]>; Tue, 16 Apr 2002 09:49:12 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1S07Q>; Tue, 16 Apr 2002 09:46:43 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.169]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1S07M; Tue, 16 Apr 2002 09:46:39 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pradeep, PK" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 16 Apr 2002 09:45:50 -0400
Subject: Re: few more basic questions
In-Reply-To: <[e-mail] iasw.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Pradeep:

There are several freeware toolkits that contain the necessary building 
blocks.  OpenSSL is one.

Some platforms have support for many of the functions as well.

Russ


At 09:43 AM 4/16/2002 +0530, Pradeep, PK wrote:
>Hello Russ/Group,
>thanks for your reply.
>
>Are there free APIs available in Java or Vb or both to
>1) build S/MIME message
>2) build PKCS#7 object to SignedData and Enveloped Data.
>
>If free APIs are not available then:
>
>Is it possible to build one's own component to build S/MIME message and
>PKCS#7 objects? As I understand basically speaking S/MIME message and
>PKCS#7 objects are nothing but a particular structure of text strings.
>if the binary portion is base64 encoded then it is nothing but text
>message. Kindly throw some light on this.
>
>Warm Regards,
>
>Pradeep
>
>-----Original Message-----
>From: Housley, Russ [mailto:[e-mail]]
>Sent: Monday, April 15, 2002 11:12 PM
>To: Pradeep, PK
>Cc: [e-mail]
>Subject: Re: a basic question
>
>
>Pradeep:
>
>In response to your beginner questions:
>
> >1. S/MIME message is a ascii (text) message or a binary message?
>
>The protected content is MIME encoded, so it can be anything.
>
> >2. suppose i have a .gif file which i am sending as attachment of
> >multipart/related MIME message. the attachment file is base64
> >transfer-encoded...the resulting MIME message is a binary message or a
>text
> >message. can the MIME message be srored as string.
>
>The result of the base64 encoding is a character string.
>
> >3. I have a multipart/signed message which i have signed using my
>private
> >key...the message is a binary message or text message?
>
>This depends on the encoding that is employed.  If base64 is used, then
>(as
>before) the output is a character string.  If a binary encoding is used,
>
>then, as expected, a binary message is the result.
>
>Russ


Received: by above.proper.com (8.11.6/8.11.3) id g3GFvvE03760 for ietf-smime-bks; Tue, 16 Apr 2002 08:57:57 -0700 (PDT)
Received: from wfhqex01.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GFvum03756 for <[e-mail]>; Tue, 16 Apr 2002 08:57:56 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: S/MIME Freeware Library  (was RE: few more basic questions)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Tue, 16 Apr 2002 11:57:51 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: few more basic questions
Thread-Index: AcHlAxPS3SgsQdM6Rhux5sDMOWKfKgAXGCCg
From: "Pawling, John" <[e-mail]>
To: "Pradeep, PK" <[e-mail]>
Cc: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3GFvum03757
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Pradeep,

Getronics Government Solutions provides freeware, open source, security
libraries at <http://www.getronicsgov.com/hot/sec_libraries.htm> that
can be incorporated into applications to help them meet security
requirements.  The S/MIME Freeware Library (SFL) implements the IETF
S/MIME v3 RFC 2630 and RFC 2634 specifications.  The Certificate
Management Library (CML) validates Version 3 X.509 certificates and
Certificate Revocation Lists (CRL) to meet the 2000 X.509 Recommendation
and IETF PKIX specifications.  These libraries use the Enhanced SNACC
Abstract Syntax Notation One (ASN.1) library.  The web site provides
further information.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================
 


-----Original Message-----
From: Pradeep, PK [mailto:[e-mail]]
Sent: Tuesday, April 16, 2002 12:14 AM
To: [e-mail]
Cc: Housley, Russ
Subject: few more basic questions



Hello Russ/Group,
thanks for your reply.

Are there free APIs available in Java or Vb or both to 
1) build S/MIME message
2) build PKCS#7 object to SignedData and Enveloped Data.

If free APIs are not available then:

Is it possible to build one's own component to build S/MIME message and
PKCS#7 objects? As I understand basically speaking S/MIME message and
PKCS#7 objects are nothing but a particular structure of text strings.
if the binary portion is base64 encoded then it is nothing but text
message. Kindly throw some light on this.

Warm Regards,

Pradeep

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Monday, April 15, 2002 11:12 PM
To: Pradeep, PK
Cc: [e-mail]
Subject: Re: a basic question


Pradeep:

In response to your beginner questions:

>1. S/MIME message is a ascii (text) message or a binary message?

The protected content is MIME encoded, so it can be anything.

>2. suppose i have a .gif file which i am sending as attachment of
>multipart/related MIME message. the attachment file is base64
>transfer-encoded...the resulting MIME message is a binary message or a
text
>message. can the MIME message be srored as string.

The result of the base64 encoding is a character string.

>3. I have a multipart/signed message which i have signed using my
private
>key...the message is a binary message or text message?

This depends on the encoding that is employed.  If base64 is used, then
(as 
before) the output is a character string.  If a binary encoding is used,

then, as expected, a binary message is the result.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GDtwE26656 for ietf-smime-bks; Tue, 16 Apr 2002 06:55:58 -0700 (PDT)
Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GDtvm26650 for <[e-mail]>; Tue, 16 Apr 2002 06:55:57 -0700 (PDT)
Received: from revelation ([12.230.197.24]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020416135543.GGYI1083.rwcrmhc53.attbi.com@revelation>; Tue, 16 Apr 2002 13:55:43 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Pradeep, PK'" <[e-mail]>, <[e-mail]>
Subject: RE: few more basic questions
Date: Tue, 16 Apr 2002 06:52:43 -0700
Message-ID: <001f01c1e54d$fbbaf260$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Look on the Microsoft web site for the CAPICOM code to do CMS and
certificate processing from VB and script.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Pradeep, PK
> Sent: Monday, April 15, 2002 9:14 PM
> To: [e-mail]
> Cc: Housley, Russ
> Subject: few more basic questions
> 
> 
> 
> Hello Russ/Group,
> thanks for your reply.
> 
> Are there free APIs available in Java or Vb or both to 
> 1) build S/MIME message
> 2) build PKCS#7 object to SignedData and Enveloped Data.
> 
> If free APIs are not available then:
> 
> Is it possible to build one's own component to build S/MIME 
> message and
> PKCS#7 objects? As I understand basically speaking S/MIME message and
> PKCS#7 objects are nothing but a particular structure of text strings.
> if the binary portion is base64 encoded then it is nothing but text
> message. Kindly throw some light on this.
> 
> Warm Regards,
> 
> Pradeep
> 
> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Monday, April 15, 2002 11:12 PM
> To: Pradeep, PK
> Cc: [e-mail]
> Subject: Re: a basic question
> 
> 
> Pradeep:
> 
> In response to your beginner questions:
> 
> >1. S/MIME message is a ascii (text) message or a binary message?
> 
> The protected content is MIME encoded, so it can be anything.
> 
> >2. suppose i have a .gif file which i am sending as attachment of
> >multipart/related MIME message. the attachment file is base64
> >transfer-encoded...the resulting MIME message is a binary 
> message or a
> text
> >message. can the MIME message be srored as string.
> 
> The result of the base64 encoding is a character string.
> 
> >3. I have a multipart/signed message which i have signed using my
> private
> >key...the message is a binary message or text message?
> 
> This depends on the encoding that is employed.  If base64 is 
> used, then
> (as 
> before) the output is a character string.  If a binary 
> encoding is used,
> 
> then, as expected, a binary message is the result.
> 
> Russ
> 



Received: by above.proper.com (8.11.6/8.11.3) id g3G48wC13099 for ietf-smime-bks; Mon, 15 Apr 2002 21:08:58 -0700 (PDT)
Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3G47am13077 for <[e-mail]>; Mon, 15 Apr 2002 21:07:37 -0700 (PDT)
Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 3274A424E; Tue, 16 Apr 2002 00:07:40 -0400 (EDT)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 79AF31257; Mon, 15 Apr 2002 23:07:34 -0500 (CDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <2CDWHB7Q>; Tue, 16 Apr 2002 09:31:39 +0530
Message-ID: <[e-mail]>
From: "Pradeep, PK" <[e-mail]>
To: [e-mail]
Cc: "Housley, Russ" <[e-mail]>
Subject: few more basic questions
Date: Tue, 16 Apr 2002 09:43:52 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
content-class: urn:content-classes:message
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Russ/Group,
thanks for your reply.

Are there free APIs available in Java or Vb or both to 
1) build S/MIME message
2) build PKCS#7 object to SignedData and Enveloped Data.

If free APIs are not available then:

Is it possible to build one's own component to build S/MIME message and
PKCS#7 objects? As I understand basically speaking S/MIME message and
PKCS#7 objects are nothing but a particular structure of text strings.
if the binary portion is base64 encoded then it is nothing but text
message. Kindly throw some light on this.

Warm Regards,

Pradeep

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Monday, April 15, 2002 11:12 PM
To: Pradeep, PK
Cc: [e-mail]
Subject: Re: a basic question


Pradeep:

In response to your beginner questions:

>1. S/MIME message is a ascii (text) message or a binary message?

The protected content is MIME encoded, so it can be anything.

>2. suppose i have a .gif file which i am sending as attachment of
>multipart/related MIME message. the attachment file is base64
>transfer-encoded...the resulting MIME message is a binary message or a
text
>message. can the MIME message be srored as string.

The result of the base64 encoding is a character string.

>3. I have a multipart/signed message which i have signed using my
private
>key...the message is a binary message or text message?

This depends on the encoding that is employed.  If base64 is used, then
(as 
before) the output is a character string.  If a binary encoding is used,

then, as expected, a binary message is the result.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FHgQY29652 for ietf-smime-bks; Mon, 15 Apr 2002 10:42:26 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3FHgOm29648 for <[e-mail]>; Mon, 15 Apr 2002 10:42:24 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 Apr 2002 17:41:17 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA14750 for <[e-mail]>; Mon, 15 Apr 2002 13:41:07 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3FHgTl16742 for <[e-mail]>; Mon, 15 Apr 2002 13:42:29 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1SW12>; Mon, 15 Apr 2002 13:40:00 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.17]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1SW1G; Mon, 15 Apr 2002 13:39:54 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pradeep, PK" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Apr 2002 13:42:13 -0400
Subject: Re: a basic question
In-Reply-To: <[e-mail] iasw.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Pradeep:

In response to your beginner questions:

>1. S/MIME message is a ascii (text) message or a binary message?

The protected content is MIME encoded, so it can be anything.

>2. suppose i have a .gif file which i am sending as attachment of
>multipart/related MIME message. the attachment file is base64
>transfer-encoded...the resulting MIME message is a binary message or a text
>message. can the MIME message be srored as string.

The result of the base64 encoding is a character string.

>3. I have a multipart/signed message which i have signed using my private
>key...the message is a binary message or text message?

This depends on the encoding that is employed.  If base64 is used, then (as 
before) the output is a character string.  If a binary encoding is used, 
then, as expected, a binary message is the result.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3D7s9R22614 for ietf-smime-bks; Sat, 13 Apr 2002 00:54:09 -0700 (PDT)
Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3D7s8m22607 for <[e-mail]>; Sat, 13 Apr 2002 00:54:08 -0700 (PDT)
Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 276703F28 for <[e-mail]>; Sat, 13 Apr 2002 02:53:59 -0500 (CDT)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id C55472269 for <[e-mail]>; Sat, 13 Apr 2002 02:53:56 -0500 (CDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <2CDWGCWK>; Sat, 13 Apr 2002 13:18:11 +0530
Message-ID: <[e-mail]>
From: "Pradeep, PK" <[e-mail]>
To: [e-mail]
Subject: a basic question
Date: Sat, 13 Apr 2002 13:30:26 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
content-class: urn:content-classes:message
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi group, 

I am new to S/MIME and MIME concepts.. I have a few very basic question..pl.
help 

1. S/MIME message is a ascii (text) message or a binary message? 
  
2. suppose i have a .gif file which i am sending as attachment of
multipart/related MIME message. the attachment file is base64
transfer-encoded...the resulting MIME message is a binary message or a text
message. can the MIME message be srored as string.

3. I have a multipart/signed message which i have signed using my private
key...the message is a binary message or text message?

thanks in advance, 

Pradeep 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35G3t321049 for ietf-smime-bks; Fri, 5 Apr 2002 08:03:55 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g35G3qm21038 for <[e-mail]>; Fri, 5 Apr 2002 08:03:52 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Apr 2002 16:02:56 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA06490 for <[e-mail]>; Fri, 5 Apr 2002 11:02:50 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g35G3tx25059 for <[e-mail]>; Fri, 5 Apr 2002 11:03:55 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1302Y>; Fri, 5 Apr 2002 11:01:30 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.145]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1302V; Fri, 5 Apr 2002 11:01:26 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 05 Apr 2002 11:03:43 -0500
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
In-Reply-To: <004401c1dc52$cf1bf730$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

I have no problem with:
         MUST SHA-1
         SHOULD MD5
         MAY MD2

Russ


At 07:34 PM 4/4/2002 -0800, Jim Schaad wrote:
>Gentlemen,
>
>I have been thinking about what the problem with this response it, I
>cannot explain it very well to my standard IT manager.
>
>One one hand we are saying - MD2 is so bad that you should never use it
>for generating signatures on S/MIME messages or certificates to be used
>with validating S/MIME purposed certificates. (MUST NOT)
>
>On the other hand we are saying - If you find a certificate with MD2 in
>it, you really need to validate it.  We lied, there are not really any
>problems with it.
>
>The difference in approaches between Blake and me boil down to the fact
>that I am writing a security document on what you really ought to do,
>and Blake is creating an interopablity document describing how the real
>world operates and what you need to do to survive there.  Given that
>this is an IETF document, I believe that correctness is the primary
>importance and compatability with the real world a secondary
>consideration.  I would rather say nothing about MD2 except it exists
>and there are potential problems (that we believe could lead to
>incorrect validation) however I can accept MAY rather than SHOULD for
>this along with the scary warning text in the security considerations.
>
>jim
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> > Sent: Saturday, March 30, 2002 10:59 AM
> > To: Blake Ramsdell
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
> >
> >
> > Blake:
> >
> > I am fine with this approach.
> >
> > Russ
> >
> >
> > At 03:55 PM 3/29/2002 -0800, Blake Ramsdell wrote:
> > >----- Original Message -----
> > >From: "Housley, Russ" <[e-mail]>
> > >To: <[e-mail]>
> > >Cc: "'Blake Ramsdell'" <[e-mail]>;
> > <[e-mail]>
> > >Sent: Friday, March 29, 2002 1:57 PM
> > >Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
> > >
> > >
> > > > I think that we should include is as a MAY for
> > validation.  I do not think
> > > > that anyone should generate new certificates that use MD2.
> > >
> > >My opinion is we should say SHOULD verify, and MUST NOT
> > generate, perhaps
> > >mentioning the known issues with MD2 in the security considerations.
> > >
> > >Blake
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g353b8o22356 for ietf-smime-bks; Thu, 4 Apr 2002 19:37:08 -0800 (PST)
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g353b7m22352 for <[e-mail]>; Thu, 4 Apr 2002 19:37:07 -0800 (PST)
Received: from revelation ([12.230.197.24]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020405033706.CHFO18078.rwcrmhc51.attbi.com@revelation>; Fri, 5 Apr 2002 03:37:06 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, "'Blake Ramsdell'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
Date: Thu, 4 Apr 2002 19:34:35 -0800
Message-ID: <004401c1dc52$cf1bf730$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Gentlemen,

I have been thinking about what the problem with this response it, I
cannot explain it very well to my standard IT manager.

One one hand we are saying - MD2 is so bad that you should never use it
for generating signatures on S/MIME messages or certificates to be used
with validating S/MIME purposed certificates. (MUST NOT) 

On the other hand we are saying - If you find a certificate with MD2 in
it, you really need to validate it.  We lied, there are not really any
problems with it.

The difference in approaches between Blake and me boil down to the fact
that I am writing a security document on what you really ought to do,
and Blake is creating an interopablity document describing how the real
world operates and what you need to do to survive there.  Given that
this is an IETF document, I believe that correctness is the primary
importance and compatability with the real world a secondary
consideration.  I would rather say nothing about MD2 except it exists
and there are potential problems (that we believe could lead to
incorrect validation) however I can accept MAY rather than SHOULD for
this along with the scary warning text in the security considerations.

jim

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]] 
> Sent: Saturday, March 30, 2002 10:59 AM
> To: Blake Ramsdell
> Cc: [e-mail]; [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
> 
> 
> Blake:
> 
> I am fine with this approach.
> 
> Russ
> 
> 
> At 03:55 PM 3/29/2002 -0800, Blake Ramsdell wrote:
> >----- Original Message -----
> >From: "Housley, Russ" <[e-mail]>
> >To: <[e-mail]>
> >Cc: "'Blake Ramsdell'" <[e-mail]>; 
> <[e-mail]>
> >Sent: Friday, March 29, 2002 1:57 PM
> >Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
> >
> >
> > > I think that we should include is as a MAY for 
> validation.  I do not think
> > > that anyone should generate new certificates that use MD2.
> >
> >My opinion is we should say SHOULD verify, and MUST NOT 
> generate, perhaps
> >mentioning the known issues with MD2 in the security considerations.
> >
> >Blake
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34ChC413136 for ietf-smime-bks; Thu, 4 Apr 2002 04:43:12 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34Ch5m13130; Thu, 4 Apr 2002 04:43:06 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g34Ch6b18330; Thu, 4 Apr 2002 13:43:06 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]>; Thu, 4 Apr 2002 13:37:46 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA16409; Thu, 4 Apr 2002 13:43:01 +0100
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 13:43:03 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: xme <[e-mail]>, Shivaram Mysore <[e-mail]>
Subject: xkms requirements document last call
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

This mail is to ask for your comments on the W3C XKMS 
requirements document. See below for details.

Sorry for the short notice - however, we will welcome comments 
for a while after the official end of the last-call period.

Thanks,
Stephen.

On behalf of the W3C XML Key Managment Service WG [1], we are 
pleased to announce the publication of the "XKMS Requirements" 
Last Call Working Draft.  This is one of the deliverables of 
the WG.  The document address is:

  http://www.w3.org/TR/xkms2-req

Abstract 

This document lists the design principles, scope and requirements 
for XML Key Management specifications and trust server key management 
implementations. It includes requirements as they relate to the key 
management syntax, processing, security and coordination with other 
standards activities. 

Status of this Document 

This is the Last Call for the requirements Working Draft of the XML Key 
Management Working Group (Activity Statement). This version represents the 
consensus of the Working Group. The last call period is 3 weeks, ending on 
15 April 2002.

Please send review comments by that date to the editors - [e-mail], 
[e-mail] and cc: [e-mail], [e-mail], 
[e-mail]

[1]  http://www.w3.org/2001/XKMS

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g32942G24233 for ietf-smime-bks; Tue, 2 Apr 2002 01:04:02 -0800 (PST)
Received: from jupiter.bj.co.uk ([195.217.233.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3293xm24221 for <[e-mail]>; Tue, 2 Apr 2002 01:04:00 -0800 (PST)
Received: from 194.72.164.27 by jupiter.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Tue, 02 Apr 2002 10:05:55 +0100
X-Server-Uuid: 3da21eb0-4d9e-11d4-96af-00b0d018dd71
Received: by bjex1.bj.co.uk with Internet Mail Service (5.5.2650.21) id <HABZK5HP>; Tue, 2 Apr 2002 10:00:29 +0100
Message-ID: <[e-mail]>
From: "Piers Chivers" <[e-mail]>
To: "'Pawling, John'" <[e-mail]>, [e-mail], "Piers Chivers" <[e-mail]>
cc: [e-mail]
Subject: RE: Labeling and SMIME
Date: Tue, 2 Apr 2002 10:00:20 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 10B7ABF927503-01-03
Content-Type: multipart/alternative;  boundary="----_=_NextPart_001_01C1DA24.D608B13A"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1DA24.D608B13A
Content-Type: text/plain; 
 charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks to everyone who responded to me, either directly or through the list,
on this.
 
I concur with the general consensus that ESS wrapping provides the
facilities that I require.  I have a mild concern with respect to the
performance of such an approach, but that's an operational, rather than a
protocol, issue.
 
Thanks again,
Piers
 
Piers Chivers
Product Architect
Protek Network Security
[phone]
www.protek.com <http://www.protek.com> 
 
-----Original Message-----
From: Pawling, John [mailto:[e-mail]] 
Sent: 21 March 2002 18:01
To: [e-mail]; Piers Chivers
Cc: [e-mail]
Subject: RE: Labeling and SMIME
 
All,
 
I believe that RFC 2630 CMS and RFC 2634 ESS allow sufficient flexibility
regarding the binding of security labels with data.  For example, the
original signer of the signedData signerInfo can apply a security label that
is bound with the original encapsulated content.  Another entity can
encapsulate the original signedData in an outer signedData in which the
entity can apply a security label that is bound with the outer signedData's
encapsulated content (i.e. the inner signedData).  An application can
unambiguously process the nested signedData layers to identify each signer
that created each security label. 
 
I agree with all of Sean Turner's statements.
 
In summary, I believe that nested signedData layers can be used to meet
Piers' requirements.  I do not believe that CMS and ESS should be changed
regarding the creation and use of security labels.  
 
=========================================== 
John Pawling, [e-mail] 
Getronics Government Solutions, LLC 
=========================================== 
-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Thursday, March 21, 2002 11:14 AM
To: 'Piers Chivers'
Cc: [e-mail]
Subject: RE: Labeling and SMIME
Piers,
 
There is another way that this can be handled depending on the order of
evalution of security labels by your software.  It would be possible to add
a new security label in a wrapping layer which both 1) gave the new label to
be used and 2) overrode the inner label.  
 
This method does have a number of possible pitfalls to be considered, 1) the
label evaluation needs to ensure that the new label applier has the right to
apply the label and 2) the change in label corresponds to some type of
policy.  This does mean that a single engine with the ability to save state
needs to be used to evaluate the labels.  This is not going to be supported
by some software, and is done purely in the label engine there needs to be a
way of making sure that all of the labels apply to a single message
(inclusion of a message id as a label parameter would be one method).
 
This allows for the concept of both lowering and upping the security level
needed to view a document.
 
jim
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Piers Chivers
Sent: Thursday, March 21, 2002 9:11 AM
To: 'Sean P. Turner'
Cc: [e-mail]
Subject: RE: Labeling and SMIME
Sean,
Thanks for the response.  Whether or not a label is part of a document and
hence changing the label changes the document is a philosophical debate.
Nevertheless, it is an important one.  I think that in a business world the
person who signs the content of a document could be different from the
person who labels a document.  Business policy should dictate who is allowed
to sign documents.  Similarly, policy should dictate who is allowed to set
or change a label.  The CMS spec doesn't allow for this.  
 
Further to my earlier suggestion, I would suggest that this should be
addressed at the CMS level.  One possibility is a signedMetaAttributes field
in the SignerInfo with a metaSignature field that is a signature of the
signedMetaAttributes.  signedMetaAttributes should always contain the
message digest attribute similar to signedAttrs.  This way the document and
the label attribute are cryptographically bound.
 
Piers
 
Piers Chivers
Product Architect
Protek Network Security
[phone]
www.protek.com <http://www.protek.com> 
 
-----Original Message-----
From: Sean P. Turner [mailto:[e-mail]] 
Sent: 20 March 2002 21:22
To: Piers Chivers
Cc: [e-mail]
Subject: Re: Labeling and SMIME
 
Piers, 
One way to allow a message to change label values over time would be to have
the message (say it's marked A, where A is higher than B) include not only
the marking A in the security label but also include an indication of when
it should be considered to be marked B.  You could do this with a security
category. 
To me you always want to link the message/document, label, and signature in
the same blob.  Firstly, if you have a document I hope you've got the
marking in the document's contents.  Then, if you have to change the
classification you'd also have to change the marking in the document;
thereby, changing the document's contents and the original signature
wouldn't be valid anymore anyway.  To me when you change the label's values
you're essentially changing the message/document and hence it ought to be
treated as a new message/document. 
spt 
Piers Chivers wrote: 
Hi,
I think that the current SMIME implementation for labeling is too
inflexible.This is probably because it is modeled on a military world where
a Top Secret message stays Top Secret for ever.However, in the commercial
world a "Commercially Sensitive" document may become "Public" overtime or
because of a change of circumstances (details released to Stock Markets,
document signed off by marketing etc.).
Since, in SMIME, the label of a message is signed with the content of the
document it is impossible for the label to be changed without re-computing a
signature on the content of the document.This is erroneous since the person
changing the label may not be the original creator of the document
contents.Hence the proof-of-origin of the document will be lost. 
Have I missed a way to do this in the current CMS/SMIME model? If not, I
would propose a scheme as follows: 
a new MIME entity application/pkcs7-labeled that has 2 parts: 
application/pkcs7-document that contains the document part of a
multipart/signed entity and 
application/pkcs7-label - a MIME entity that contains a signed CMS object
containing the label and the original document's detached signature.The
latter signature is provided by the person who creates the message.The outer
signed CMS object is signed by the labeler of the document.Typically, the
signatories will be the same person. 
This approach allows labeled documents to be re-classified over time but
keeps the original document signature. 
Any thoughts? 
Thanks, 
Piers 
Piers Chivers 
Product Architect 
Protek Network Security 
[phone] 
www.protek.com <http://www.protek.com>  

--------------------------------------------------------------------------------
This message is for the named person's use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient.  PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all email communications through its network.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.



------_=_NextPart_001_01C1DA24.D608B13A
Content-Type: text/html; 
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[e-mail]1C9730">
<title>Message</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"time"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"date"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle20
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.EmailStyle21
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2
	{mso-style-name:"Table Colorful 2";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	border:none;
	border-bottom:solid black 1.5pt;
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:gray-20 yellow;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2FirstRow
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-row;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid maroon;
	mso-tstyle-border-bottom:1.5pt solid black;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	color:white;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2FirstCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-column;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2LastCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:last-column;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid silver;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;}
table.MsoTableColorful2SWCell
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:sw-cell;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks to everyone who responded =
to me,
either directly or through the list, on =
this.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I concur with the general =
consensus that ESS
wrapping provides the facilities that I require.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>I have a mild concern with =
respect to
the performance of such an approach, but that's an operational, rather
than a protocol, issue.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks =
again,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Piers<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<div>

<p class=3DMsoAutoSig><st1:PersonName><font size=3D2 color=3Dnavy
 face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;
 mso-ansi-language:EN-GB;mso-no-proof:yes'>Piers =
Chivers</span></font></st1:PersonName><font
size=3D2 color=3Dnavy><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;
mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;mso-ansi-language:EN-GB;
mso-no-proof:yes'>Product Architect</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;mso-ansi-language:EN-GB;
mso-no-proof:yes'>Protek Network Security<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;mso-ansi-language:EN-GB;
mso-no-proof:yes'>[phone]<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><u><font size=3D2 color=3D"#0080ff" face=3D"Times =
New Roman"><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;mso-ansi-language:EN-GB;
mso-no-proof:yes'><a =
href=3D"http://www.protek.com">www.protek.com</a></span></font></u><font=

size=3D2 color=3D"#0080ff"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;
mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Pawling, John
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><st1:date
Month=3D"3" Day=3D"21" Year=3D"2002"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
 10.0pt;font-family:Tahoma'>21 March 2002</span></font></st1:date><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
</span></font><st1:time
Hour=3D"18" Minute=3D"1"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
 font-family:Tahoma'>18:01</span></font></st1:time><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]; =
Piers
Chivers<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Labeling =
and SMIME</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>All,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>I believe that RFC
2630&nbsp;CMS and RFC 2634 ESS allow&nbsp;sufficient flexibility =
regarding the
binding of&nbsp;security labels with data.&nbsp; For example, the =
original
signer of the signedData signerInfo can apply a security label that is =
bound
with the original encapsulated content.&nbsp; Another entity can =
encapsulate
the original signedData in an outer signedData in which the =
entity&nbsp;can
apply a&nbsp;security label that is bound with the&nbsp;outer =
signedData's
encapsulated content (i.e. the inner
signedData).&nbsp;&nbsp;An&nbsp;application&nbsp;can&nbsp;unambiguously =
process
the nested signedData layers to&nbsp;identify each&nbsp;signer
that&nbsp;created each security =
label.&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>I agree with =
all of Sean
Turner's statements.<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>In summary, =
I&nbsp;believe
that nested signedData layers can be used to meet Piers' =
requirements.&nbsp; I
do not believe that CMS and ESS should be changed regarding the =
creation and
use&nbsp;of security labels.&nbsp; </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>
John Pawling, [e-mail] <br>
Getronics Government Solutions, LLC <br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
<o:p></o:p></span></font></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:
12.0pt;margin-left:36.0pt'><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Jim Schaad
[mailto:[e-mail]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><st1:date
Month=3D"3" Day=3D"21" Year=3D"2002"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
 10.0pt;font-family:Tahoma'>Thursday, March 21, =
2002</span></font></st1:date><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> </span></font><st1:time
Hour=3D"11" Minute=3D"14"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
 font-family:Tahoma'>11:14 AM</span></font></st1:time><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Piers Chivers'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Labeling =
and SMIME</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblue
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Piers,</span></f=
ont><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblue
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>There is
another way that this can be handled depending on the order of =
evalution of
security labels by your software.&nbsp; It would be possible to add a =
new
security label in a wrapping layer which both 1) gave the new label to =
be used
and 2) overrode the inner label.&nbsp; </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblue
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>This
method does have a number of possible pitfalls to be considered, 1) the =
label
evaluation needs to ensure that the new label applier has the right to =
apply
the label and 2) the change in label corresponds to some type of =
policy.&nbsp;
This does mean that a single engine with the ability to save state =
needs to be
used to evaluate the labels.&nbsp; This is not going to be supported by =
some
software, and is done purely in the label engine there needs to be a =
way of
making sure that all of the labels apply to a single message (inclusion =
of a
message id as a label parameter would be one =
method).</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblue
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>This
allows for the concept of both lowering and upping the security level =
needed to
view a document.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblue
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>jim</span></font=
><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt=
'>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:
12.0pt;margin-left:36.0pt'><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Piers Chivers<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><st1:date
Month=3D"3" Day=3D"21" Year=3D"2002"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
 10.0pt;font-family:Tahoma'>Thursday, March 21, =
2002</span></font></st1:date><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> </span></font><st1:time
Hour=3D"9" Minute=3D"11"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
 font-family:Tahoma'>9:11 AM</span></font></st1:time><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Sean P. Turner'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Labeling =
and SMIME</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Sean,<o:p></o:p>=
</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Thanks
for the response.<span style=3D'mso-spacerun:yes'>&nbsp; </span>Whether =
or not a
label is part of a document and hence changing the label changes the =
document
is a philosophical debate.<span style=3D'mso-spacerun:yes'>&nbsp;
</span>Nevertheless, it is an important one.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>I think that in a business =
world the
person who signs the content of a document could be different from the =
person
who labels a document.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>Business
policy should dictate who is allowed to sign documents.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Similarly, policy should =
dictate who is
allowed to set or change a label.<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>The CMS spec doesn't allow for this.<span
style=3D'mso-spacerun:yes'>&nbsp; </span><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p=
></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Further
to my earlier suggestion, I would suggest that this should be addressed =
at the
CMS level.<span style=3D'mso-spacerun:yes'>&nbsp; </span>One =
possibility is a
signedMetaAttributes field in the SignerInfo with a metaSignature field =
that is
a signature of the signedMetaAttributes.<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>signedMetaAttributes should always contain the message digest =
attribute
similar to signedAttrs.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>This way
the document and the label attribute are cryptographically =
bound.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p=
></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Piers<o:p></o:p>=
</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p=
></span></font></p>

<div>

<p class=3DMsoAutoSig style=3D'margin-left:36.0pt'><st1:PersonName
style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"><font
 size=3D2 color=3Dnavy face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:
 10.0pt;color:navy;mso-ansi-language:EN-GB;mso-no-proof:yes'>Piers =
Chivers</span></font></st1:PersonName><font
size=3D2 color=3Dnavy><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;
mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=3DMsoAutoSig style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dnavy
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;
mso-ansi-language:EN-GB;mso-no-proof:yes'>Product =
Architect</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=3DMsoAutoSig style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dnavy
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;
mso-ansi-language:EN-GB;mso-no-proof:yes'>Protek Network =
Security<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dnavy
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;
mso-ansi-language:EN-GB;mso-no-proof:yes'>+44 (0)1270 =
507800<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig style=3D'margin-left:36.0pt'><u><font size=3D2 =
color=3D"#0080ff"
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;
mso-ansi-language:EN-GB;mso-no-proof:yes'><a =
href=3D"http://www.protek.com">www.protek.com</a></span></font></u><font=

size=3D2 color=3D"#0080ff"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;
mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p=
></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Sean P. Turner
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><st1:date
Month=3D"3" Day=3D"20" Year=3D"2002"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
 10.0pt;font-family:Tahoma'>20 March 2002</span></font></st1:date><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
</span></font><st1:time
Hour=3D"21" Minute=3D"22"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
 font-family:Tahoma'>21:22</span></font></st1:time><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> Piers Chivers<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Labeling =
and SMIME</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Piers, =
<o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>One way to allow a message to change label =
values over
time would be to have the message (say it's marked A, where A is higher =
than B)
include not only the marking A in the security label but also include =
an
indication of when it should be considered to be marked B.&nbsp; You =
could do
this with a security category. <o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>To me you always want to link the =
message/document,
label, and signature in the same blob.&nbsp; Firstly, if you have a =
document I
hope you've got the marking in the document's contents.&nbsp; Then, if =
you have
to change the classification you'd also have to change the marking in =
the
document; thereby, changing the document's contents and the original =
signature
wouldn't be valid anymore anyway.&nbsp; To me when you change the =
label's
values you're essentially changing the message/document and hence it =
ought to
be treated as a new message/document. <o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>spt <o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Piers Chivers wrote: =
<o:p></o:p></span></font></p>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
TYPE=3DCITE><U1:SMARTTAGTYPE =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"/><!--[if gte mso 9]><xml>
 <u1:OfficeDocumentSettings>
  <u1:DoNotRelyOnCSS/>
 </u1:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <u2:WordDocument>
  <u2:SpellingState>Clean</u2:SpellingState>
  <u2:GrammarState>Clean</u2:GrammarState>
  <u2:DocumentKind>DocumentEmail</u2:DocumentKind>
  <u2:EnvelopeVis/>
  <u2:Compatibility>
   <u2:BreakWrappedTables/>
   <u2:SnapToGridInCell/>
   <u2:WrapTextWithPunct/>
   <u2:UseAsianBreakRules/>
  </u2:Compatibility>
  <u2:BrowserLevel>MicrosoftInternetExplorer4</u2:BrowserLevel>
 </u2:WordDocument>
</xml><![endif]-->

<div>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Hi,<U1:P></U1:P></span></fo=
nt><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>I think that the current =
SMIME
implementation for labeling is too inflexible.This is probably because =
it is
modeled on a military world where a Top Secret message stays Top Secret =
for
ever.However, in the commercial world a &quot;Commercially =
Sensitive&quot;
document may become &quot;Public&quot; overtime or because of a change =
of
circumstances (details released to Stock Markets, document signed off =
by
marketing etc.).<U1:P></U1:P></span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><U1:P></U1:P>Since, in =
SMIME, the
label of a message is signed with the content of the document it is =
impossible
for the label to be changed without re-computing a signature on the =
content of
the document.This is erroneous since the person changing the label may =
not be
the original creator of the document contents.Hence the proof-of-origin =
of the
document will be lost.<U1:P></U1:P></span></font> <o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><U1:P></U1:P>Have I missed =
a way to
do this in the current CMS/SMIME model? If not, I would propose a =
scheme as
follows:<U1:P></U1:P></span></font> <o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><U1:P></U1:P>a new MIME =
entity
application/pkcs7-labeled that has 2 parts:<U1:P></U1:P></span></font> =
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><U1:P></U1:P>application/pk=
cs7-document
that contains the document part of a multipart/signed entity =
and<U1:P></U1:P></span></font>
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><U1:P></U1:P>application/pk=
cs7-label
- a MIME entity that contains a signed CMS object containing the label =
and the
original document's detached signature.The latter signature is provided =
by the
person who creates the message.The outer signed CMS object is signed by =
the
labeler of the document.Typically, the signatories will be the same =
person.<U1:P></U1:P></span></font>
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><U1:P></U1:P>This approach =
allows
labeled documents to be re-classified over time but keeps the original =
document
signature.<U1:P></U1:P></span></font> <o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><U1:P></U1:P>Any =
thoughts?</span></font><U1:P></U1:P>
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><U1:P></U1:P>Thanks,<U1:P><=
/U1:P></span></font>
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Piers<U1:P></U1:P></span></=
font> <o:p></o:p></p>

<p class=3DMsoAutoSig style=3D'margin-left:72.0pt'><st1:PersonName
style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"><font
 size=3D2 face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
 mso-ansi-language:EN-GB;mso-no-proof:yes'><U1:P></U1:P>Piers =
Chivers</span></font></st1:PersonName><span
lang=3DEN-GB style=3D'mso-ansi-language:EN-GB'><U1:P></U1:P> =
</span><o:p></o:p></p>

<p class=3DMsoAutoSig style=3D'margin-left:72.0pt'><font size=3D2
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;mso-ansi-language:
EN-GB;mso-no-proof:yes'>Product Architect</span></font><span =
lang=3DEN-GB
style=3D'mso-ansi-language:EN-GB'><U1:P></U1:P> </span><o:p></o:p></p>

<p class=3DMsoAutoSig style=3D'margin-left:72.0pt'><font size=3D2
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;mso-ansi-language:
EN-GB;mso-no-proof:yes'>Protek Network =
Security<U1:P></U1:P></span></font><span
lang=3DEN-GB style=3D'mso-ansi-language:EN-GB'> </span><o:p></o:p></p>

<p class=3DMsoAutoSig style=3D'margin-left:72.0pt'><font size=3D2
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;mso-ansi-language:
EN-GB;mso-no-proof:yes'>+44 (0)1270 =
507800<U1:P></U1:P></span></font><span
lang=3DEN-GB style=3D'mso-ansi-language:EN-GB'> </span><o:p></o:p></p>

<p class=3DMsoAutoSig style=3D'margin-left:72.0pt'><u><font size=3D2 =
color=3D"#0080ff"
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;
mso-ansi-language:EN-GB;mso-no-proof:yes'><a =
href=3D"http://www.protek.com">www.protek.com</a></span></font></u><span=

lang=3DEN-GB style=3D'mso-ansi-language:EN-GB'><U1:P></U1:P> =
</span><o:p></o:p></p>

</blockquote>

</blockquote>

</blockquote>

</div>

<U1:P></U1:P>
</body>

</html>

--------------------------------------------------------------------------------<br>
This message is for the named person's use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient.  PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all email communications through its network.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.<br>
<br>
<br>

------_=_NextPart_001_01C1DA24.D608B13A--