Subject: Get $200 bonus at our Casino!

From: "Lilian G. Henderson" <[email-masked]>
Date: Wed, 30 Jun 2004 21:04:52 +0400

Hi, 
I have a special offer available for you at our casino.

$20 to try our internet casino, no deposit is necessary!
At the casino software's cashier enter bonus code: FR93P

$200 bonus on your first deposit!
At the casino software's cashier enter bonus code: FMJKU

Allow us to show you our quality operation, fast payouts,
generous bonuses, and super friendly around-the-clock
customer support.

Click here: http://gocasino-dollar.com

Best regards,
Jamie Zawinsky

No thanks: http://gocasino-dollar.com/u

Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Mon, 28 Jun 2004 08:48:36 +1200
From: "Craig McGregor" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, "Ben Littauer" <[email-masked]>, <[email-masked]>
content-class: urn:content-classes:message
Sender: [email-masked]

Trevor,

I do not believe there is a need for a new signature format - existing
S/MIME formats could be used. Perhaps an e-mail gateway / MTA  just
needs to know that the other side supports domain-to-domain signing
and/or encryption.

Perhaps something similar to RFC3183? Or, http://e.govt.nz/see/mail? Or,
http://www.mahealthdata.org/initiatives/e-mail/phases.html?
But spec'd for use in an open-community rather than a closed-community?

Regards,
Craig

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Trevor Freeman
> Sent: Friday, 25 June 2004 5:42 a.m.
> To: Ben Littauer; [email-masked]
> Subject: RE: Anti-spam news article / S/MIME Gateways
> 
> 
> 
> Hi Ben
> I agree there are issues with the trust mechanisms etc.
> Domain signing is a good idea. What has that to do with the 
> format and encoding of how you sign a message? What part of 
> CMS is so horribly broken that we need another signature 
> format? Trevor
> 
> * -----Original Message-----
> * From: [email-masked]
> [mailto:[email-masked]]
> * On Behalf Of Ben Littauer
> * Sent: Wednesday, June 23, 2004 6:34 AM
> * To: [email-masked]
> * Subject: Re: Anti-spam news article / S/MIME Gateways
> * 
> * 
> * There's scalability and there's scalability.
> * 
> * The problem with desktop to desktop PKI is both the 
> directory problem
> * (i.e.
> * key discovery and distribution) and the administration 
> problem (issuance,
> * renewal, and revocation of certificates).  Domain-level PKI 
> reduces the
> * scale of both problems by several orders of magnitude.  
> Solving the domain
> * level problems first will perhaps give some clue to the mechanisms
> * required
> * for the desktop implementation, should it ever become required.
> * 
> * -ben-
> * 
> * > From: "Trevor Freeman" <[email-masked]>
> * > Date: Tue, 22 Jun 2004 11:15:39 -0700
> * > To: "Craig McGregor" <[email-masked]>, 
> "Russ Housley"
> * > <[email-masked]>, <[email-masked]>
> * > Subject: RE: Anti-spam news article / S/MIME Gateways
> * >
> * >
> * > Hi Craig,
> * > While I understand you comments about closed groups. The 
> real problem
> * > with scaling beyond closed groups is, as you point out, trust
> * > mechanisms. What I fail to see is why we need a different 
> signature
> * > format to deploy a more scalable trust mechanism.
> * > Trevor
> * >
> * > * -----Original Message-----
> * > * From: [email-masked]
> * > [mailto:[email-masked]]
> * > * On Behalf Of Craig McGregor
> * > * Sent: Monday, June 21, 2004 8:12 PM
> * > * To: Russ Housley; [email-masked]
> * > * Subject: RE: Anti-spam news article / S/MIME Gateways
> * > *
> * > *
> * > *
> * > * >Tumbleweed Chief Executive Jeff Smith says there's a lot of
> * > * misunderstanding about
> * > * >S/MIME, because it was created as a desktop encryption 
> technology. He
> * > * argues it's
> * > * > also simple and cost-effective to use as a gateway 
> authentication
> * > * technology, and
> * > * > that its quality advantages make it the best choice. 
> Tumbleweed
> * > would
> * > * like to work
> * > * > with Yahoo to merge their technologies.
> * > *
> * > * S/MIME gateway software in the context of a 
> 'closed-community' is a
> * > * proven method of authenticating the sending domains of 
> e-mail messages
> * > * and has been effective at blocking increased volumes of 
> spoofed e-mail
> * > * messages (providing they were sent from a participating 
> domain). And
> * > of
> * > * cause using S/MIME encryption protects one from in-transit
> * > eavesdropping
> * > * too!
> * > *
> * > * Applying what is quite managable in a 'closed-community' for an
> * > * Internet-wide deployment would be somewhat more 
> challenging though.
> * > * Particularly around certificate deployment, trust-chains and
> * > * auto-discovery (assume DNS for internet-wide; a 
> 'closed-community'
> * > could
> * > * use LDAP). I think that is why domain keys proposes to 
> trust DNS data
> * > as
> * > * being authorative without any further validation.
> * > *
> * > * Craig.
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * >
> 
> 
> 

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'David P. Kemp'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Anti-spam news article / S/MIME Gateways
Date: Fri, 25 Jun 2004 09:43:41 -0700
Sender: [email-masked]

The debate I hope to carry here is that domain keys should be a subset of
smime and not try to design yet another message format.

That way we can get end to end in the end or at least when relevant. 

I would guess that you guys also have cases where end to end is not the best
approach. 

Time to ditch the dogma. The real prolem with ideology is that it is usually
part way right, problem is that it isn't completely right.

 -----Original Message-----
From: 	David P. Kemp [mailto:[email-masked]]
Sent:	Fri Jun 25 08:03:32 2004
To:	Hallam-Baker, Phillip
Cc:	[email-masked]
Subject:	Re: Anti-spam news article / S/MIME Gateways

Phill,

I'll look forward to the draft, to better understand what is needed
beyond user agent enhancements and "better discovery protocols".

    Client A  ---------> GW A -----------> GW B --------> Client B
                              \--------> GW C ---------> Client C

1. Assume no clients support S/MIME, A sends a message to B and C;
GW A needs to discover the gateways serving B and C and encrypt
to the appropriate GWs.

2. Assume only Client B supports S/MIME, GW A needs to discover
GW C and the fact that User B has a cert.

3. Assume only Clients A and B support S/MIME, Client A needs to
discover User B's cert and discover GW C's cert as a proxy for
email address of user C.

An in-band signalling mechanism can only work between signalling-
enabled nodes, which I assume means S/MIME-enabled nodes.  What
kind of signalling is needed other than agreed mechanisms
for handling mixtures of "[email-masked]" gateway certs, [email-masked]
user certs, and Bob (no email address, multi-mail-server) user
certs.  In other words, I don't see what in-band signalling
(contained in messages vs. certificates) you have in mind.

Of course we bone-heads want to ensure that when end-to-end
is available, a MITM can't exploit gateway features to bypass
it.  But that just means that end-to-end must have priority,
not that it's end-to-end or nothing.

Dave

Hallam-Baker, Phillip wrote:
> Trevor,
> 
> 	The CMS format is fine, 95% of the spec is fine.
> 
> 	The problem is that there is a 5% gap between what S/MIME delivers
> and what is needed.
> 
> 	I think we can close the gap, the key is to throw away the bone
> headed insistence that some people had concerning the end to end model or
> nothing. We tried that for ten years, we ended up with nothing. IPSEC
makes
> a lousy VPN protocol for the exact same reason, give me something that
> really works through a NAT box without complaint any day.
> 
> 	What is needed is more than just better discovery protocols, or
> logos in the certs. We need better client interfaces, we also need an in
> band signalling mechanism so you know that when S/MIME enhancements are
> being added that the channel can support them, including stripping them
out
> if some appliance or client turns out not to support them.
> 
> 	[Draft to follow]
> 
> 		Phill

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>, "'Ben Littauer'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Fri, 25 Jun 2004 09:07:34 -0700
Sender: [email-masked]

Absolutely, there is no point in reopening the message format issue. All
that does is move us back to the start.

The missing 5% is the stuff that is the diference between security for geeks
and security for real people.

 -----Original Message-----
From: 	Trevor Freeman [mailto:[email-masked]]
Sent:	Fri Jun 25 07:45:20 2004
To:	Hallam-Baker, Phillip; Ben Littauer; [email-masked]
Subject:	RE: Anti-spam news article / S/MIME Gateways

Hi Phil,
I agree that the end-to-end model is part of the problem. There is
obvious some ground to cover, but I am much more comfortable just fixing
what is broken and reusing what is not. There is no value in reinventing
another wheel - life is to short.
Trevor

* -----Original Message-----
* From: Hallam-Baker, Phillip [mailto:[email-masked]]
* Sent: Thursday, June 24, 2004 9:44 PM
* To: Trevor Freeman; Ben Littauer; [email-masked]
* Subject: RE: Anti-spam news article / S/MIME Gateways
* 
* Trevor,
* 
* 	The CMS format is fine, 95% of the spec is fine.
* 
* 	The problem is that there is a 5% gap between what S/MIME
delivers
* and what is needed.
* 
* 	I think we can close the gap, the key is to throw away the bone
* headed insistence that some people had concerning the end to end model
or
* nothing. We tried that for ten years, we ended up with nothing. IPSEC
* makes
* a lousy VPN protocol for the exact same reason, give me something that
* really works through a NAT box without complaint any day.
* 
* 	What is needed is more than just better discovery protocols, or
* logos in the certs. We need better client interfaces, we also need an
in
* band signalling mechanism so you know that when S/MIME enhancements
are
* being added that the channel can support them, including stripping
them
* out
* if some appliance or client turns out not to support them.
* 
* 	[Draft to follow]
* 
* 		Phill
* 
* > -----Original Message-----
* > From: [email-masked]
* > [mailto:[email-masked]]On Behalf Of Trevor Freeman
* > Sent: Thursday, June 24, 2004 1:42 PM
* > To: Ben Littauer; [email-masked]
* > Subject: RE: Anti-spam news article / S/MIME Gateways
* >
* >
* >
* > Hi Ben
* > I agree there are issues with the trust mechanisms etc. Domain
signing
* > is a good idea. What has that to do with the format and
* > encoding of how
* > you sign a message? What part of CMS is so horribly broken
* > that we need
* > another signature format?
* > Trevor
* >
* > * -----Original Message-----
* > * From: [email-masked]
* > [mailto:[email-masked]]
* > * On Behalf Of Ben Littauer
* > * Sent: Wednesday, June 23, 2004 6:34 AM
* > * To: [email-masked]
* > * Subject: Re: Anti-spam news article / S/MIME Gateways
* > *
* > *
* > * There's scalability and there's scalability.
* > *
* > * The problem with desktop to desktop PKI is both the
* > directory problem
* > * (i.e.
* > * key discovery and distribution) and the administration problem
* > (issuance,
* > * renewal, and revocation of certificates).  Domain-level PKI
reduces
* > the
* > * scale of both problems by several orders of magnitude.  Solving
the
* > domain
* > * level problems first will perhaps give some clue to the mechanisms
* > * required
* > * for the desktop implementation, should it ever become required.
* > *
* > * -ben-
* > *
* > * > From: "Trevor Freeman" <[email-masked]>
* > * > Date: Tue, 22 Jun 2004 11:15:39 -0700
* > * > To: "Craig McGregor" <[email-masked]>, "Russ
* > Housley"
* > * > <[email-masked]>, <[email-masked]>
* > * > Subject: RE: Anti-spam news article / S/MIME Gateways
* > * >
* > * >
* > * > Hi Craig,
* > * > While I understand you comments about closed groups. The real
* > problem
* > * > with scaling beyond closed groups is, as you point out, trust
* > * > mechanisms. What I fail to see is why we need a different
* > signature
* > * > format to deploy a more scalable trust mechanism.
* > * > Trevor
* > * >
* > * > * -----Original Message-----
* > * > * From: [email-masked]
* > * > [mailto:[email-masked]]
* > * > * On Behalf Of Craig McGregor
* > * > * Sent: Monday, June 21, 2004 8:12 PM
* > * > * To: Russ Housley; [email-masked]
* > * > * Subject: RE: Anti-spam news article / S/MIME Gateways
* > * > *
* > * > *
* > * > *
* > * > * >Tumbleweed Chief Executive Jeff Smith says there's a lot of
* > * > * misunderstanding about
* > * > * >S/MIME, because it was created as a desktop encryption
* > technology. He
* > * > * argues it's
* > * > * > also simple and cost-effective to use as a gateway
* > authentication
* > * > * technology, and
* > * > * > that its quality advantages make it the best choice.
* > Tumbleweed
* > * > would
* > * > * like to work
* > * > * > with Yahoo to merge their technologies.
* > * > *
* > * > * S/MIME gateway software in the context of a
* > 'closed-community' is
* > a
* > * > * proven method of authenticating the sending domains of e-mail
* > messages
* > * > * and has been effective at blocking increased volumes of
spoofed
* > e-mail
* > * > * messages (providing they were sent from a participating
domain).
* > And
* > * > of
* > * > * cause using S/MIME encryption protects one from in-transit
* > * > eavesdropping
* > * > * too!
* > * > *
* > * > * Applying what is quite managable in a 'closed-community' for
an
* > * > * Internet-wide deployment would be somewhat more challenging
* > though.
* > * > * Particularly around certificate deployment, trust-chains and
* > * > * auto-discovery (assume DNS for internet-wide; a
* > 'closed-community'
* > * > could
* > * > * use LDAP). I think that is why domain keys proposes to trust
DNS
* > data
* > * > as
* > * > * being authorative without any further validation.
* > * > *
* > * > * Craig.
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * >
* >
* >

Content-class: urn:content-classes:message
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Fri, 25 Jun 2004 07:45:09 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "Ben Littauer" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Phil,
I agree that the end-to-end model is part of the problem. There is
obvious some ground to cover, but I am much more comfortable just fixing
what is broken and reusing what is not. There is no value in reinventing
another wheel - life is to short.
Trevor

* -----Original Message-----
* From: Hallam-Baker, Phillip [mailto:[email-masked]]
* Sent: Thursday, June 24, 2004 9:44 PM
* To: Trevor Freeman; Ben Littauer; [email-masked]
* Subject: RE: Anti-spam news article / S/MIME Gateways
* 
* Trevor,
* 
* 	The CMS format is fine, 95% of the spec is fine.
* 
* 	The problem is that there is a 5% gap between what S/MIME
delivers
* and what is needed.
* 
* 	I think we can close the gap, the key is to throw away the bone
* headed insistence that some people had concerning the end to end model
or
* nothing. We tried that for ten years, we ended up with nothing. IPSEC
* makes
* a lousy VPN protocol for the exact same reason, give me something that
* really works through a NAT box without complaint any day.
* 
* 	What is needed is more than just better discovery protocols, or
* logos in the certs. We need better client interfaces, we also need an
in
* band signalling mechanism so you know that when S/MIME enhancements
are
* being added that the channel can support them, including stripping
them
* out
* if some appliance or client turns out not to support them.
* 
* 	[Draft to follow]
* 
* 		Phill
* 
* > -----Original Message-----
* > From: [email-masked]
* > [mailto:[email-masked]]On Behalf Of Trevor Freeman
* > Sent: Thursday, June 24, 2004 1:42 PM
* > To: Ben Littauer; [email-masked]
* > Subject: RE: Anti-spam news article / S/MIME Gateways
* >
* >
* >
* > Hi Ben
* > I agree there are issues with the trust mechanisms etc. Domain
signing
* > is a good idea. What has that to do with the format and
* > encoding of how
* > you sign a message? What part of CMS is so horribly broken
* > that we need
* > another signature format?
* > Trevor
* >
* > * -----Original Message-----
* > * From: [email-masked]
* > [mailto:[email-masked]]
* > * On Behalf Of Ben Littauer
* > * Sent: Wednesday, June 23, 2004 6:34 AM
* > * To: [email-masked]
* > * Subject: Re: Anti-spam news article / S/MIME Gateways
* > *
* > *
* > * There's scalability and there's scalability.
* > *
* > * The problem with desktop to desktop PKI is both the
* > directory problem
* > * (i.e.
* > * key discovery and distribution) and the administration problem
* > (issuance,
* > * renewal, and revocation of certificates).  Domain-level PKI
reduces
* > the
* > * scale of both problems by several orders of magnitude.  Solving
the
* > domain
* > * level problems first will perhaps give some clue to the mechanisms
* > * required
* > * for the desktop implementation, should it ever become required.
* > *
* > * -ben-
* > *
* > * > From: "Trevor Freeman" <[email-masked]>
* > * > Date: Tue, 22 Jun 2004 11:15:39 -0700
* > * > To: "Craig McGregor" <[email-masked]>, "Russ
* > Housley"
* > * > <[email-masked]>, <[email-masked]>
* > * > Subject: RE: Anti-spam news article / S/MIME Gateways
* > * >
* > * >
* > * > Hi Craig,
* > * > While I understand you comments about closed groups. The real
* > problem
* > * > with scaling beyond closed groups is, as you point out, trust
* > * > mechanisms. What I fail to see is why we need a different
* > signature
* > * > format to deploy a more scalable trust mechanism.
* > * > Trevor
* > * >
* > * > * -----Original Message-----
* > * > * From: [email-masked]
* > * > [mailto:[email-masked]]
* > * > * On Behalf Of Craig McGregor
* > * > * Sent: Monday, June 21, 2004 8:12 PM
* > * > * To: Russ Housley; [email-masked]
* > * > * Subject: RE: Anti-spam news article / S/MIME Gateways
* > * > *
* > * > *
* > * > *
* > * > * >Tumbleweed Chief Executive Jeff Smith says there's a lot of
* > * > * misunderstanding about
* > * > * >S/MIME, because it was created as a desktop encryption
* > technology. He
* > * > * argues it's
* > * > * > also simple and cost-effective to use as a gateway
* > authentication
* > * > * technology, and
* > * > * > that its quality advantages make it the best choice.
* > Tumbleweed
* > * > would
* > * > * like to work
* > * > * > with Yahoo to merge their technologies.
* > * > *
* > * > * S/MIME gateway software in the context of a
* > 'closed-community' is
* > a
* > * > * proven method of authenticating the sending domains of e-mail
* > messages
* > * > * and has been effective at blocking increased volumes of
spoofed
* > e-mail
* > * > * messages (providing they were sent from a participating
domain).
* > And
* > * > of
* > * > * cause using S/MIME encryption protects one from in-transit
* > * > eavesdropping
* > * > * too!
* > * > *
* > * > * Applying what is quite managable in a 'closed-community' for
an
* > * > * Internet-wide deployment would be somewhat more challenging
* > though.
* > * > * Particularly around certificate deployment, trust-chains and
* > * > * auto-discovery (assume DNS for internet-wide; a
* > 'closed-community'
* > * > could
* > * > * use LDAP). I think that is why domain keys proposes to trust
DNS
* > data
* > * > as
* > * > * being authorative without any further validation.
* > * > *
* > * > * Craig.
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * >
* >
* >

Date: Fri, 25 Jun 2004 09:12:03 -0400
From: "David P. Kemp" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
CC: [email-masked]
Subject: Re: Anti-spam news article / S/MIME Gateways
Sender: [email-masked]

Phill,

I'll look forward to the draft, to better understand what is needed
beyond user agent enhancements and "better discovery protocols".

    Client A  ---------> GW A -----------> GW B --------> Client B
                              \--------> GW C ---------> Client C

1. Assume no clients support S/MIME, A sends a message to B and C;
GW A needs to discover the gateways serving B and C and encrypt
to the appropriate GWs.

2. Assume only Client B supports S/MIME, GW A needs to discover
GW C and the fact that User B has a cert.

3. Assume only Clients A and B support S/MIME, Client A needs to
discover User B's cert and discover GW C's cert as a proxy for
email address of user C.

An in-band signalling mechanism can only work between signalling-
enabled nodes, which I assume means S/MIME-enabled nodes.  What
kind of signalling is needed other than agreed mechanisms
for handling mixtures of "[email-masked]" gateway certs, [email-masked]
user certs, and Bob (no email address, multi-mail-server) user
certs.  In other words, I don't see what in-band signalling
(contained in messages vs. certificates) you have in mind.

Of course we bone-heads want to ensure that when end-to-end
is available, a MITM can't exploit gateway features to bypass
it.  But that just means that end-to-end must have priority,
not that it's end-to-end or nothing.

Dave

Hallam-Baker, Phillip wrote:
> Trevor,
> 
> 	The CMS format is fine, 95% of the spec is fine.
> 
> 	The problem is that there is a 5% gap between what S/MIME delivers
> and what is needed.
> 
> 	I think we can close the gap, the key is to throw away the bone
> headed insistence that some people had concerning the end to end model or
> nothing. We tried that for ten years, we ended up with nothing. IPSEC makes
> a lousy VPN protocol for the exact same reason, give me something that
> really works through a NAT box without complaint any day.
> 
> 	What is needed is more than just better discovery protocols, or
> logos in the certs. We need better client interfaces, we also need an in
> band signalling mechanism so you know that when S/MIME enhancements are
> being added that the channel can support them, including stripping them out
> if some appliance or client turns out not to support them.
> 
> 	[Draft to follow]
> 
> 		Phill

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>, Ben Littauer <[email-masked]>, [email-masked]
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Thu, 24 Jun 2004 21:44:12 -0700
Sender: [email-masked]

Trevor,

	The CMS format is fine, 95% of the spec is fine.

	The problem is that there is a 5% gap between what S/MIME delivers
and what is needed.

	I think we can close the gap, the key is to throw away the bone
headed insistence that some people had concerning the end to end model or
nothing. We tried that for ten years, we ended up with nothing. IPSEC makes
a lousy VPN protocol for the exact same reason, give me something that
really works through a NAT box without complaint any day.

	What is needed is more than just better discovery protocols, or
logos in the certs. We need better client interfaces, we also need an in
band signalling mechanism so you know that when S/MIME enhancements are
being added that the channel can support them, including stripping them out
if some appliance or client turns out not to support them.

	[Draft to follow]

		Phill

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Trevor Freeman
> Sent: Thursday, June 24, 2004 1:42 PM
> To: Ben Littauer; [email-masked]
> Subject: RE: Anti-spam news article / S/MIME Gateways
> 
> 
> 
> Hi Ben
> I agree there are issues with the trust mechanisms etc. Domain signing
> is a good idea. What has that to do with the format and 
> encoding of how
> you sign a message? What part of CMS is so horribly broken 
> that we need
> another signature format?
> Trevor
> 
> * -----Original Message-----
> * From: [email-masked]
> [mailto:[email-masked]]
> * On Behalf Of Ben Littauer
> * Sent: Wednesday, June 23, 2004 6:34 AM
> * To: [email-masked]
> * Subject: Re: Anti-spam news article / S/MIME Gateways
> * 
> * 
> * There's scalability and there's scalability.
> * 
> * The problem with desktop to desktop PKI is both the 
> directory problem
> * (i.e.
> * key discovery and distribution) and the administration problem
> (issuance,
> * renewal, and revocation of certificates).  Domain-level PKI reduces
> the
> * scale of both problems by several orders of magnitude.  Solving the
> domain
> * level problems first will perhaps give some clue to the mechanisms
> * required
> * for the desktop implementation, should it ever become required.
> * 
> * -ben-
> * 
> * > From: "Trevor Freeman" <[email-masked]>
> * > Date: Tue, 22 Jun 2004 11:15:39 -0700
> * > To: "Craig McGregor" <[email-masked]>, "Russ
> Housley"
> * > <[email-masked]>, <[email-masked]>
> * > Subject: RE: Anti-spam news article / S/MIME Gateways
> * >
> * >
> * > Hi Craig,
> * > While I understand you comments about closed groups. The real
> problem
> * > with scaling beyond closed groups is, as you point out, trust
> * > mechanisms. What I fail to see is why we need a different 
> signature
> * > format to deploy a more scalable trust mechanism.
> * > Trevor
> * >
> * > * -----Original Message-----
> * > * From: [email-masked]
> * > [mailto:[email-masked]]
> * > * On Behalf Of Craig McGregor
> * > * Sent: Monday, June 21, 2004 8:12 PM
> * > * To: Russ Housley; [email-masked]
> * > * Subject: RE: Anti-spam news article / S/MIME Gateways
> * > *
> * > *
> * > *
> * > * >Tumbleweed Chief Executive Jeff Smith says there's a lot of
> * > * misunderstanding about
> * > * >S/MIME, because it was created as a desktop encryption
> technology. He
> * > * argues it's
> * > * > also simple and cost-effective to use as a gateway
> authentication
> * > * technology, and
> * > * > that its quality advantages make it the best choice. 
> Tumbleweed
> * > would
> * > * like to work
> * > * > with Yahoo to merge their technologies.
> * > *
> * > * S/MIME gateway software in the context of a 
> 'closed-community' is
> a
> * > * proven method of authenticating the sending domains of e-mail
> messages
> * > * and has been effective at blocking increased volumes of spoofed
> e-mail
> * > * messages (providing they were sent from a participating domain).
> And
> * > of
> * > * cause using S/MIME encryption protects one from in-transit
> * > eavesdropping
> * > * too!
> * > *
> * > * Applying what is quite managable in a 'closed-community' for an
> * > * Internet-wide deployment would be somewhat more challenging
> though.
> * > * Particularly around certificate deployment, trust-chains and
> * > * auto-discovery (assume DNS for internet-wide; a 
> 'closed-community'
> * > could
> * > * use LDAP). I think that is why domain keys proposes to trust DNS
> data
> * > as
> * > * being authorative without any further validation.
> * > *
> * > * Craig.
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * >
> 
> 

Date: Thu, 24 Jun 2004 20:21:34 -0400
Subject: Re: Anti-spam news article / S/MIME Gateways
From: Ben Littauer <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I think we're on the same page here.  I don't see a need for major changes
in the signature format (although the semantics change), but the key
distribution mechanism is very important.

-ben-

> From: "Trevor Freeman" <[email-masked]>
> Date: Thu, 24 Jun 2004 10:42:01 -0700
> To: "Ben Littauer" <[email-masked]>, <[email-masked]>
> Subject: RE: Anti-spam news article / S/MIME Gateways
> 
> 
> Hi Ben
> I agree there are issues with the trust mechanisms etc. Domain signing
> is a good idea. What has that to do with the format and encoding of how
> you sign a message? What part of CMS is so horribly broken that we need
> another signature format?
> Trevor
> 
> * -----Original Message-----
> * From: [email-masked]
> [mailto:[email-masked]]
> * On Behalf Of Ben Littauer
> * Sent: Wednesday, June 23, 2004 6:34 AM
> * To: [email-masked]
> * Subject: Re: Anti-spam news article / S/MIME Gateways
> * 
> * 
> * There's scalability and there's scalability.
> * 
> * The problem with desktop to desktop PKI is both the directory problem
> * (i.e.
> * key discovery and distribution) and the administration problem
> (issuance,
> * renewal, and revocation of certificates).  Domain-level PKI reduces
> the
> * scale of both problems by several orders of magnitude.  Solving the
> domain
> * level problems first will perhaps give some clue to the mechanisms
> * required
> * for the desktop implementation, should it ever become required.
> * 
> * -ben-
> * 
> * > From: "Trevor Freeman" <[email-masked]>
> * > Date: Tue, 22 Jun 2004 11:15:39 -0700
> * > To: "Craig McGregor" <[email-masked]>, "Russ
> Housley"
> * > <[email-masked]>, <[email-masked]>
> * > Subject: RE: Anti-spam news article / S/MIME Gateways
> * >
> * >
> * > Hi Craig,
> * > While I understand you comments about closed groups. The real
> problem
> * > with scaling beyond closed groups is, as you point out, trust
> * > mechanisms. What I fail to see is why we need a different signature
> * > format to deploy a more scalable trust mechanism.
> * > Trevor
> * >
> * > * -----Original Message-----
> * > * From: [email-masked]
> * > [mailto:[email-masked]]
> * > * On Behalf Of Craig McGregor
> * > * Sent: Monday, June 21, 2004 8:12 PM
> * > * To: Russ Housley; [email-masked]
> * > * Subject: RE: Anti-spam news article / S/MIME Gateways
> * > *
> * > *
> * > *
> * > * >Tumbleweed Chief Executive Jeff Smith says there's a lot of
> * > * misunderstanding about
> * > * >S/MIME, because it was created as a desktop encryption
> technology. He
> * > * argues it's
> * > * > also simple and cost-effective to use as a gateway
> authentication
> * > * technology, and
> * > * > that its quality advantages make it the best choice. Tumbleweed
> * > would
> * > * like to work
> * > * > with Yahoo to merge their technologies.
> * > *
> * > * S/MIME gateway software in the context of a 'closed-community' is
> a
> * > * proven method of authenticating the sending domains of e-mail
> messages
> * > * and has been effective at blocking increased volumes of spoofed
> e-mail
> * > * messages (providing they were sent from a participating domain).
> And
> * > of
> * > * cause using S/MIME encryption protects one from in-transit
> * > eavesdropping
> * > * too!
> * > *
> * > * Applying what is quite managable in a 'closed-community' for an
> * > * Internet-wide deployment would be somewhat more challenging
> though.
> * > * Particularly around certificate deployment, trust-chains and
> * > * auto-discovery (assume DNS for internet-wide; a 'closed-community'
> * > could
> * > * use LDAP). I think that is why domain keys proposes to trust DNS
> data
> * > as
> * > * being authorative without any further validation.
> * > *
> * > * Craig.
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * >
> 

Content-class: urn:content-classes:message
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Thu, 24 Jun 2004 10:42:01 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Ben Littauer" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Ben
I agree there are issues with the trust mechanisms etc. Domain signing
is a good idea. What has that to do with the format and encoding of how
you sign a message? What part of CMS is so horribly broken that we need
another signature format?
Trevor

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Ben Littauer
* Sent: Wednesday, June 23, 2004 6:34 AM
* To: [email-masked]
* Subject: Re: Anti-spam news article / S/MIME Gateways
* 
* 
* There's scalability and there's scalability.
* 
* The problem with desktop to desktop PKI is both the directory problem
* (i.e.
* key discovery and distribution) and the administration problem
(issuance,
* renewal, and revocation of certificates).  Domain-level PKI reduces
the
* scale of both problems by several orders of magnitude.  Solving the
domain
* level problems first will perhaps give some clue to the mechanisms
* required
* for the desktop implementation, should it ever become required.
* 
* -ben-
* 
* > From: "Trevor Freeman" <[email-masked]>
* > Date: Tue, 22 Jun 2004 11:15:39 -0700
* > To: "Craig McGregor" <[email-masked]>, "Russ
Housley"
* > <[email-masked]>, <[email-masked]>
* > Subject: RE: Anti-spam news article / S/MIME Gateways
* >
* >
* > Hi Craig,
* > While I understand you comments about closed groups. The real
problem
* > with scaling beyond closed groups is, as you point out, trust
* > mechanisms. What I fail to see is why we need a different signature
* > format to deploy a more scalable trust mechanism.
* > Trevor
* >
* > * -----Original Message-----
* > * From: [email-masked]
* > [mailto:[email-masked]]
* > * On Behalf Of Craig McGregor
* > * Sent: Monday, June 21, 2004 8:12 PM
* > * To: Russ Housley; [email-masked]
* > * Subject: RE: Anti-spam news article / S/MIME Gateways
* > *
* > *
* > *
* > * >Tumbleweed Chief Executive Jeff Smith says there's a lot of
* > * misunderstanding about
* > * >S/MIME, because it was created as a desktop encryption
technology. He
* > * argues it's
* > * > also simple and cost-effective to use as a gateway
authentication
* > * technology, and
* > * > that its quality advantages make it the best choice. Tumbleweed
* > would
* > * like to work
* > * > with Yahoo to merge their technologies.
* > *
* > * S/MIME gateway software in the context of a 'closed-community' is
a
* > * proven method of authenticating the sending domains of e-mail
messages
* > * and has been effective at blocking increased volumes of spoofed
e-mail
* > * messages (providing they were sent from a participating domain).
And
* > of
* > * cause using S/MIME encryption protects one from in-transit
* > eavesdropping
* > * too!
* > *
* > * Applying what is quite managable in a 'closed-community' for an
* > * Internet-wide deployment would be somewhat more challenging
though.
* > * Particularly around certificate deployment, trust-chains and
* > * auto-discovery (assume DNS for internet-wide; a 'closed-community'
* > could
* > * use LDAP). I think that is why domain keys proposes to trust DNS
data
* > as
* > * being authorative without any further validation.
* > *
* > * Craig.
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* >

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'Use of the SEED Encryption Algorithm in CMS' to Proposed  Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Wed, 23 Jun 2004 17:45:11 -0400
Sender: [email-masked]

The IESG has received a request from the S/MIME Mail Security WG to consider 
the following document:

- 'Use of the SEED Encryption Algorithm in CMS '
   <draft-ietf-smime-cms-seed-01.txt> as a Proposed Standard

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

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-seed-01.txt

Date: Wed, 23 Jun 2004 14:24:35 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Content Collection
Sender: [email-masked]

Please take a look at the following individual contribution.  I wrote it 
because some people are using CMS in environments that do not include 
MIME.  Obviously, S/MIME does not fall into this category.  I am asking for 
review here because this is the IETF WG with the most CMS experience.

http://www.ietf.org/internet-drafts/draft-housley-contentcollection-00.txt

Thanks,
   Russ

Date: Wed, 23 Jun 2004 09:34:06 -0400
Subject: Re: Anti-spam news article / S/MIME Gateways
From: Ben Littauer <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

There's scalability and there's scalability.

The problem with desktop to desktop PKI is both the directory problem (i.e.
key discovery and distribution) and the administration problem (issuance,
renewal, and revocation of certificates).  Domain-level PKI reduces the
scale of both problems by several orders of magnitude.  Solving the domain
level problems first will perhaps give some clue to the mechanisms required
for the desktop implementation, should it ever become required.

-ben-

> From: "Trevor Freeman" <[email-masked]>
> Date: Tue, 22 Jun 2004 11:15:39 -0700
> To: "Craig McGregor" <[email-masked]>, "Russ Housley"
> <[email-masked]>, <[email-masked]>
> Subject: RE: Anti-spam news article / S/MIME Gateways
> 
> 
> Hi Craig,
> While I understand you comments about closed groups. The real problem
> with scaling beyond closed groups is, as you point out, trust
> mechanisms. What I fail to see is why we need a different signature
> format to deploy a more scalable trust mechanism.
> Trevor
> 
> * -----Original Message-----
> * From: [email-masked]
> [mailto:[email-masked]]
> * On Behalf Of Craig McGregor
> * Sent: Monday, June 21, 2004 8:12 PM
> * To: Russ Housley; [email-masked]
> * Subject: RE: Anti-spam news article / S/MIME Gateways
> * 
> * 
> * 
> * >Tumbleweed Chief Executive Jeff Smith says there's a lot of
> * misunderstanding about
> * >S/MIME, because it was created as a desktop encryption technology. He
> * argues it's
> * > also simple and cost-effective to use as a gateway authentication
> * technology, and
> * > that its quality advantages make it the best choice. Tumbleweed
> would
> * like to work
> * > with Yahoo to merge their technologies.
> * 
> * S/MIME gateway software in the context of a 'closed-community' is a
> * proven method of authenticating the sending domains of e-mail messages
> * and has been effective at blocking increased volumes of spoofed e-mail
> * messages (providing they were sent from a participating domain). And
> of
> * cause using S/MIME encryption protects one from in-transit
> eavesdropping
> * too!
> * 
> * Applying what is quite managable in a 'closed-community' for an
> * Internet-wide deployment would be somewhat more challenging though.
> * Particularly around certificate deployment, trust-chains and
> * auto-discovery (assume DNS for internet-wide; a 'closed-community'
> could
> * use LDAP). I think that is why domain keys proposes to trust DNS data
> as
> * being authorative without any further validation.
> * 
> * Craig.
> * 
> * 
> * 
> * 
> * 
> * 
> * 
> * 
> * 
> * 
> * 
> * 
> 

Content-class: urn:content-classes:message
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Tue, 22 Jun 2004 11:15:39 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Craig McGregor" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Craig,
While I understand you comments about closed groups. The real problem
with scaling beyond closed groups is, as you point out, trust
mechanisms. What I fail to see is why we need a different signature
format to deploy a more scalable trust mechanism. 
Trevor

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Craig McGregor
* Sent: Monday, June 21, 2004 8:12 PM
* To: Russ Housley; [email-masked]
* Subject: RE: Anti-spam news article / S/MIME Gateways
* 
* 
* 
* >Tumbleweed Chief Executive Jeff Smith says there's a lot of
* misunderstanding about
* >S/MIME, because it was created as a desktop encryption technology. He
* argues it's
* > also simple and cost-effective to use as a gateway authentication
* technology, and
* > that its quality advantages make it the best choice. Tumbleweed
would
* like to work
* > with Yahoo to merge their technologies.
* 
* S/MIME gateway software in the context of a 'closed-community' is a
* proven method of authenticating the sending domains of e-mail messages
* and has been effective at blocking increased volumes of spoofed e-mail
* messages (providing they were sent from a participating domain). And
of
* cause using S/MIME encryption protects one from in-transit
eavesdropping
* too!
* 
* Applying what is quite managable in a 'closed-community' for an
* Internet-wide deployment would be somewhat more challenging though.
* Particularly around certificate deployment, trust-chains and
* auto-discovery (assume DNS for internet-wide; a 'closed-community'
could
* use LDAP). I think that is why domain keys proposes to trust DNS data
as
* being authorative without any further validation.
* 
* Craig.
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Craig McGregor'" <[email-masked]>, Russ Housley <[email-masked]>, [email-masked]
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Tue, 22 Jun 2004 11:13:41 -0700
Sender: [email-masked]

> S/MIME gateway software in the context of a 'closed-community' is a
> proven method of authenticating the sending domains of e-mail messages
> and has been effective at blocking increased volumes of spoofed e-mail
> messages (providing they were sent from a participating 
> domain). And of
> cause using S/MIME encryption protects one from in-transit 
> eavesdropping
> too! 

Quite, and don't forget that TLS can add value.

> Applying what is quite managable in a 'closed-community' for an
> Internet-wide deployment would be somewhat more challenging though.
> Particularly around certificate deployment, trust-chains and
> auto-discovery (assume DNS for internet-wide; a 
> 'closed-community' could
> use LDAP). I think that is why domain keys proposes to trust 
> DNS data as
> being authorative without any further validation.

Storing keys in the DNS has its place, any technique to obtain
a rough authentication of a domain key is worthwhile. I do not
think the technique works when you get down to the user level.

I entirely disagree on the LDAP issue. I think that LDAP has
had its chance as an Internet protocol and the use that it has
found will never pass beyond the firewall (which contrary to
some thought will not go away).

LDAP is a BAD certificate discovery protocol. It provides none
of the support that is really needed, except in the simplest
trust models where support is unnecessary. XKMS does the job much
better. SCVP might prove to be of use, but the time for deploying
new ASN.1 based protocols has gone. We have seen the future and
it has angle brackets arround it.

Date: Tue, 22 Jun 2004 14:08:18 -0400
From: Matt Bertapelle <[email-masked]>
To: imc-sfl <[email-masked]>, [email-masked]
Subject: v2.4 S/MIME Freeware Library (SFL) Now Available
Sender: [email-masked]

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

All,

DigitalNet Government Solutions has delivered the Version 2.4 S/MIME Freeware Library (SFL) source code.  The SFL source code files and documents are freely available at 
<http://www.digitalnet.com/knowledge/sfl_home.htm>.  

The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications.  It implements portions of the RFC 2633 Message Specification, RFC 2632 Certificate Handling, and RFC 3370 CMS Algorithms specifications.  When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method 
specification.  It has been successfully tested using the Microsoft (MS) Windows 2000/XP, Linux and Sun Solaris 2.8 operating systems.  Further enhancements, ports and testing of the SFL are still in process.  Further releases of the SFL will be provided as significant capabilities are added. 

The SFL has been successfully used to sign, verify, encrypt and decrypt 
CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the 
Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0
Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms 
provided by the Fortezza Crypto Card.  The v2.4 SFL uses the v2.4 
Certificate Management Library (CML) and v1.6 Enhanced SNACC (eSNACC) 
ASN.1 C++ Library to encode/decode objects.  The v2.4 SFL release 
includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token
Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; 
PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; test utilities; test drivers;
and test data.  All CTILs were tested as Dynamically Linked Libraries
(DLL) using MS Windows.  The Fortezza, BSAFE and Crypto++ CTILs
were tested with the respective security libraries as shared objects
using Linux and Solaris 2.8.  

The SFL has been successfully used to exchange signedData and 
envelopedData messages with the MS Internet Explorer Outlook Express 
v4.01, Netscape Communicator 4.X, Entrust and Baltimore S/MIME 
products.  Signed messages have been exchanged with the RSA S/MAIL and 
WorldTalk S/MIME v2 products. 

The SFL has also been used to perform S/MIME v3 interoperability 
testing with Microsoft that exercised the majority of the features 
specified by RFCs 3369, 3370, 2631 and 2634.  This testing included the
RSA, DSA, E-S D-H, 3DES, SHA and Fortezza algorithms.  We used the SFL 
to successfully process the SFL-supported sample data included in the
S/MIME WG "Examples of S/MIME Messages" document.  We also used the
SFL to generate S/MIME v3 sample messages that were included in the 
"Examples" document.

The use of the v2.4 SFL is described in the v2.4 SFL Application 
Programming Interface (API) and v2.4 SFL Software Design Description
documents.  The use of the v2.4 CTIL API is described in the v2.4
CTIL API document. 

v2.4 SFL includes the following enhancements (compared to v2.3
SFL and CTIL releases):

1) Added support for the creation and processing of the RFC 
3161-compliant Time Stamp Token content type.

2) Enhanced API to accomodate reciept hash.

3) Enhanced ASN.1 encode/decode functions with "Certificate Management 
Messages over CMS".

v2.4 CTILs include the following enhancements (compared to v2.3 release):

1) Added PKCS#11 interface for Crypto++.

2) Added key generation library for generating public/private 
key pairs, wrapping the private keys, and generating PKCS#12 files.

3) Added support for RFC 2437 PKCS #1 Optimal Asymetric Encryption Padding 
(RSAES-OAEP) key transport method of key management.

The SFL is developed to maximize portability to 32-bit operating 
systems.  In addition to testing on MS Windows, Linux and Solaris 2.8, 
we may port the SFL to other operating systems.

All source code for the SFL is being provided at no cost and with no 
financial limitations regarding its use and distribution. 
Organizations can use the SFL without paying any royalties or 
licensing fees.  DigitalNet is developing the SFL under contract to 
the U.S. Government.  The U.S. Government is furnishing the SFL
source code at no cost to the vendor subject to the conditions of 
the "SFL Public License".

On 14 January 2000, the U.S. Department of Commerce, Bureau of 
Export Administration published a new regulation implementing an update 
to the U.S. Government's encryption export policy 
<http://www.bxa.doc.gov/Encryption/Default.htm>.  In accordance with 
the revisions to the Export Administration Regulations (EAR) of 14 Jan 
2000, the downloading of the SFL source code is not password controlled.

The SFL is composed of a high-level library that performs generic CMS 
and ESS processing independent of the crypto algorithms used to 
protect a specific object.  The SFL high-level library makes calls to 
an algorithm-independent CTIL API.  The underlying, external crypto
token libraries are not distributed as part of the SFL source code. 
The application developer must independently obtain these libraries and
then link them with the SFL.  
 
The SFL uses the CML and eSNACC ASN.1 Library to encode/decode
certificates, ACs, CRLs and components thereof.  The CML is freely
available at: <http://www.DigitalNet.com/knowledge/cml_home.htm>.

The SFL has been successfully tested in conjunction with the Access
Control Library (ACL) that is freely available to everyone from: 
<http://www.DigitalNet.com/knowledge/acl_home.htm>.

The National Institute of Standards and Technology (NIST) is providing 
test S/MIME messages (created by DigitalNet) at 
<http://csrc.nist.gov/pki/testing/x509paths.html>.  
DigitalNet used the SFL to successfully process the NIST test data.

NIST is using the SFL and CML as part of the NIST S/MIME Test 
Facility (NSMTF) that they are planning to host (see 
<http://csrc.ncsl.nist.gov/pki/smime/>).  Vendors will be able to use
the NSMTF to help determine if their products comply with the
IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile. 

The SFL has been integrated into many applications to provide CMS/ESS
security services.  For example, the SFL was integrated into a security
plug-in for a commercial e-mail application that enabled the 
application to meet the Bridge Certification Authority Demonstration 
Phase II requirements including implementing ESS features such as
security labels.

The Internet Mail Consortium (IMC) has established an SFL web page
<http://www.imc.org/imc-sfl>.  The IMC has also established an SFL
mail list which is used to: distribute information regarding SFL
releases; discuss SFL-related issues; and provide a means for SFL
users to provide feedback, comments, bug reports, etc.  Subscription
information for the imc-sfl mailing list is at the IMC web site
listed above.

All comments regarding the SFL source code and documents are welcome.  
This SFL release announcement was sent to several mail lists, but 
please send all messages regarding the SFL to the imc-sfl mail list 
ONLY.  Please do not send messages regarding the SFL to any of the IETF 
mail lists.  We will respond to all messages sent to the imc-sfl mail 
list.

-- 
Matthew J. Bertapelle
DigitalNet Government Solutions, LLC
www.DigitalNet.com

--------------030905080900040904080104
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<pre wrap="">All,

DigitalNet Government Solutions has delivered the Version 2.4 S/MIME Freeware Library (SFL) source code.  The SFL source code files and documents are freely available at 
<a class="moz-txt-link-rfc2396E"
 href="http://www.digitalnet.com/hot/sfl_home.htm">&lt;http://www.digitalnet.com/knowledge/sfl_home.htm&gt;</a>.  

The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications.  It implements portions of the RFC 2633 Message Specification, RFC 2632 Certificate Handling, and RFC 3370 CMS Algorithms specifications.  When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method 
specification.  It has been successfully tested using the Microsoft (MS) Windows 2000/XP, Linux and Sun Solaris 2.8 operating systems.  Further enhancements, ports and testing of the SFL are still in process.  Further releases of the SFL will be provided as significant capabilities are added. 

The SFL has been successfully used to sign, verify, encrypt and decrypt 
CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the 
Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0
Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms 
provided by the Fortezza Crypto Card.  The v2.4 SFL uses the v2.4 
Certificate Management Library (CML) and v1.6 Enhanced SNACC (eSNACC) 
ASN.1 C++ Library to encode/decode objects.  The v2.4 SFL release 
includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token
Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; 
PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; test utilities; test drivers;
and test data.  All CTILs were tested as Dynamically Linked Libraries
(DLL) using MS Windows.  The Fortezza, BSAFE and Crypto++ CTILs
were tested with the respective security libraries as shared objects
using Linux and Solaris 2.8.  

The SFL has been successfully used to exchange signedData and 
envelopedData messages with the MS Internet Explorer Outlook Express 
v4.01, Netscape Communicator 4.X, Entrust and Baltimore S/MIME 
products.  Signed messages have been exchanged with the RSA S/MAIL and 
WorldTalk S/MIME v2 products. 

The SFL has also been used to perform S/MIME v3 interoperability 
testing with Microsoft that exercised the majority of the features 
specified by RFCs 3369, 3370, 2631 and 2634.  This testing included the
RSA, DSA, E-S D-H, 3DES, SHA and Fortezza algorithms.  We used the SFL 
to successfully process the SFL-supported sample data included in the
S/MIME WG "Examples of S/MIME Messages" document.  We also used the
SFL to generate S/MIME v3 sample messages that were included in the 
"Examples" document.

The use of the v2.4 SFL is described in the v2.4 SFL Application 
Programming Interface (API) and v2.4 SFL Software Design Description
documents.  The use of the v2.4 CTIL API is described in the v2.4
CTIL API document. 

v2.4 SFL includes the following enhancements (compared to v2.3
SFL and CTIL releases):
</pre>
<tt><br>
</tt><tt>1) Added support for the creation and processing of the RFC
3161-compliant Time Stamp Token content type.<br>
<br>
2) Enhanced API to accomodate reciept hash.<br>
<br>
3) Enhanced ASN.1 encode/decode functions with "Certificate Management
Messages over CMS".</tt><br>
<tt><br>
</tt><tt></tt><tt><u1:p></u1:p></tt>
<pre wrap="">v2.4 CTILs include the following enhancements (compared to v2.3 release):

<tt>1) Added PKCS#11 interface for Crypto++.

2) Added key generation library for generating public/private 
key pairs, wrapping the private keys, and generating PKCS#12 files.

3) Added support for RFC 2437 PKCS #1 Optimal Asymetric Encryption Padding 
(RSAES-OAEP) key transport method of key management.</tt></pre>
<pre wrap="">The SFL is developed to maximize portability to 32-bit operating 
systems.  In addition to testing on MS Windows, Linux and Solaris 2.8, 
we may port the SFL to other operating systems.

All source code for the SFL is being provided at no cost and with no 
financial limitations regarding its use and distribution. 
Organizations can use the SFL without paying any royalties or 
licensing fees.  DigitalNet is developing the SFL under contract to 
the U.S. Government.  The U.S. Government is furnishing the SFL
source code at no cost to the vendor subject to the conditions of 
the "SFL Public License".

On 14 January 2000, the U.S. Department of Commerce, Bureau of 
Export Administration published a new regulation implementing an update 
to the U.S. Government's encryption export policy 
<a class="moz-txt-link-rfc2396E"
 href="http://www.bxa.doc.gov/Encryption/Default.htm">&lt;http://www.bxa.doc.gov/Encryption/Default.htm&gt;</a>.  In accordance with 
the revisions to the Export Administration Regulations (EAR) of 14 Jan 
2000, the downloading of the SFL source code is not password controlled.

The SFL is composed of a high-level library that performs generic CMS 
and ESS processing independent of the crypto algorithms used to 
protect a specific object.  The SFL high-level library makes calls to 
an algorithm-independent CTIL API.  The underlying, external crypto
token libraries are not distributed as part of the SFL source code. 
The application developer must independently obtain these libraries and
then link them with the SFL.  
 
The SFL uses the CML and eSNACC ASN.1 Library to encode/decode
certificates, ACs, CRLs and components thereof.  The CML is freely
available at: <a
 class="moz-txt-link-rfc2396E"
 href="http://www.DigitalNet.com/hot/cml_home.htm">&lt;http://www.DigitalNet.com/knowledge/cml_home.htm&gt;</a>.

The SFL has been successfully tested in conjunction with the Access
Control Library (ACL) that is freely available to everyone from: 
<a class="moz-txt-link-rfc2396E"
 href="http://www.DigitalNet.com/hot/acl_home.htm">&lt;http://www.DigitalNet.com/knowledge/acl_home.htm&gt;</a>.

The National Institute of Standards and Technology (NIST) is providing 
test S/MIME messages (created by DigitalNet) at 
<a class="moz-txt-link-rfc2396E"
 href="http://csrc.nist.gov/pki/testing/x509paths.html">&lt;http://csrc.nist.gov/pki/testing/x509paths.html&gt;</a>.  
DigitalNet used the SFL to successfully process the NIST test data.

NIST is using the SFL and CML as part of the NIST S/MIME Test 
Facility (NSMTF) that they are planning to host (see 
<a class="moz-txt-link-rfc2396E"
 href="http://csrc.ncsl.nist.gov/pki/smime/">&lt;http://csrc.ncsl.nist.gov/pki/smime/&gt;</a>).  Vendors will be able to use
the NSMTF to help determine if their products comply with the
IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile. 

The SFL has been integrated into many applications to provide CMS/ESS
security services.  For example, the SFL was integrated into a security
plug-in for a commercial e-mail application that enabled the 
application to meet the Bridge Certification Authority Demonstration 
Phase II requirements including implementing ESS features such as
security labels.

The Internet Mail Consortium (IMC) has established an SFL web page
<a class="moz-txt-link-rfc2396E" href="http://www.imc.org/imc-sfl">&lt;http://www.imc.org/imc-sfl&gt;</a>.  The IMC has also established an SFL
mail list which is used to: distribute information regarding SFL
releases; discuss SFL-related issues; and provide a means for SFL
users to provide feedback, comments, bug reports, etc.  Subscription
information for the imc-sfl mailing list is at the IMC web site
listed above.

All comments regarding the SFL source code and documents are welcome.  
This SFL release announcement was sent to several mail lists, but 
please send all messages regarding the SFL to the imc-sfl mail list 
ONLY.  Please do not send messages regarding the SFL to any of the IETF 
mail lists.  We will respond to all messages sent to the imc-sfl mail 
list.</pre>
<pre class="moz-signature" cols="72">-- 
Matthew J. Bertapelle
DigitalNet Government Solutions, LLC
<a class="moz-txt-link-abbreviated" href="http://www.DigitalNet.com">www.DigitalNet.com</a></pre>
<br>
</body>
</html>

--------------030905080900040904080104--

Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Tue, 22 Jun 2004 15:12:14 +1200
From: "Craig McGregor" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
content-class: urn:content-classes:message
Sender: [email-masked]

>Tumbleweed Chief Executive Jeff Smith says there's a lot of
misunderstanding about 
>S/MIME, because it was created as a desktop encryption technology. He
argues it's
> also simple and cost-effective to use as a gateway authentication
technology, and
> that its quality advantages make it the best choice. Tumbleweed would
like to work
> with Yahoo to merge their technologies.

S/MIME gateway software in the context of a 'closed-community' is a
proven method of authenticating the sending domains of e-mail messages
and has been effective at blocking increased volumes of spoofed e-mail
messages (providing they were sent from a participating domain). And of
cause using S/MIME encryption protects one from in-transit eavesdropping
too! 

Applying what is quite managable in a 'closed-community' for an
Internet-wide deployment would be somewhat more challenging though.
Particularly around certificate deployment, trust-chains and
auto-discovery (assume DNS for internet-wide; a 'closed-community' could
use LDAP). I think that is why domain keys proposes to trust DNS data as
being authorative without any further validation.

Craig.

Content-class: urn:content-classes:message
Subject: RE: SMIME Capabilities in X.509 Certificates
Date: Fri, 18 Jun 2004 16:14:56 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>, "smime mailing list" <[email-masked]>
Cc: "smime chair" <[email-masked]>, "smime chair" <[email-masked]>
Sender: [email-masked]

Yes,

You have summarized this well.

This work will not impact any S/MIME message profiles, but we may
consider addressing this new extension in the Certificate Handling
document (or future version of it).

/Stefan

> -----Original Message-----
> From: Blake Ramsdell [mailto:[email-masked]]
> Sent: den 17 juni 2004 21:24
> To: Stefan Santesson; 'smime mailing list'
> Cc: 'smime chair'; 'smime chair'
> Subject: RE: SMIME Capabilities in X.509 Certificates
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stefan Santesson
> > Sent: Monday, June 14, 2004 7:24 PM
> > To: smime mailing list
> > Cc: smime chair; smime chair
> > Subject: SMIME Capabilities in X.509 Certificates
> >
> > It would thus improve the situation if CAs, especially enterprise
CAs,
> > that knows or even have the capability to dictate the capabilities
of
> > users, could include the PKCS#9 SMIMECapabilities attribute in
> > certificates.
> 
> OK, so as far as I can tell, what's being asked is as follows:
> 
> * Modification of the ietf-smime charter to allow for the discussion
of
> a profile of the SMIME Capabilities extension to be included in X.509
> certificates
> 
> * The actual discussion of such a thing on the ietf-smime mailing list
> 
> * Creation of one or more drafts to summarize the consensus,
ultimately
> resulting in one or more RFCs in the S/MIME working group
> 
> This all sounds like stuff we can do. If there's something I'm
missing,
> someone point it out, otherwise it seems reasonable to undertake this
> work in the working group.
> 
> One other thing we should probably discuss is whether or not this
effort
> has any impact on S/MIME message processing, and if we need to address
> that.
> 
> Blake

From: "Blake Ramsdell" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "'smime mailing list'" <[email-masked]>
Cc: "'smime chair'" <[email-masked]>, "'smime chair'" <[email-masked]>
Subject: RE: SMIME Capabilities in X.509 Certificates
Date: Thu, 17 Jun 2004 21:23:53 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Sent: Monday, June 14, 2004 7:24 PM
> To: smime mailing list
> Cc: smime chair; smime chair
> Subject: SMIME Capabilities in X.509 Certificates
> 
> It would thus improve the situation if CAs, especially enterprise CAs,
> that knows or even have the capability to dictate the capabilities of
> users, could include the PKCS#9 SMIMECapabilities attribute in
> certificates.

OK, so as far as I can tell, what's being asked is as follows:

* Modification of the ietf-smime charter to allow for the discussion of
a profile of the SMIME Capabilities extension to be included in X.509
certificates

* The actual discussion of such a thing on the ietf-smime mailing list

* Creation of one or more drafts to summarize the consensus, ultimately
resulting in one or more RFCs in the S/MIME working group

This all sounds like stuff we can do. If there's something I'm missing,
someone point it out, otherwise it seems reasonable to undertake this
work in the working group.

One other thing we should probably discuss is whether or not this effort
has any impact on S/MIME message processing, and if we need to address
that.

Blake

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, smime mailing list <[email-masked]>, smime chair <[email-masked]>, smime chair <[email-masked]>
Subject: Protocol Action: 'Cryptographic Message Syntax (CMS)' to  Proposed Standard 
Date: Wed, 16 Jun 2004 15:22:58 -0400
Sender: [email-masked]

The IESG has approved the following document:

- 'Cryptographic Message Syntax (CMS) '
   <draft-ietf-smime-rfc3369bis-04.txt> as a Proposed Standard

This document is the product of the S/MIME Mail Security Working Group. 

The IESG contact persons are Steve Bellovin and Russ Housley.

Technical Summary
 This document is a minor update from RFC 3369.  It corrects some errors, and
makes provision for easy addition of new certificate types.
 
Working Group Summary
 
 The changes were uncontroversial.
 
Protocol Quality
 
 Steve Bellovin reviewed this document for the IESG.

Content-class: urn:content-classes:message
Subject: SMIME Capabilities in X.509 Certificates
Date: Tue, 15 Jun 2004 03:23:44 +0100
From: "Stefan Santesson" <[email-masked]>
To: "smime mailing list" <[email-masked]>
Cc: "smime chair" <[email-masked]>, "smime chair" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4527F.C753D126
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stefan Santesson
Program Manager, Windows Security
Principal Consultant, Microsoft Denmark
Please find attached a proposed updated charter which would incorporate
the task to define means to carry SMIME Capabilities in X.509
Certificates.

This revised charter has been reviewed and approved by Russ Hously on
the condition that this WG accept to take on this task.

We had a discussion on this issue in PKIX which some of you may have
noticed where a majority concluded that this was a good thing to do but
the post discussion, especially with Russ, also concluded that SMIME is
probably the best place to do it and not PKIX.

The background of this work item is the need to establish knowledge
about opponents SMIME Capabilities, even before a first message
exchange. We will never escape the fact that a sender of an encrypted
mail some times will have to guess the recipients cryptographic
capabilities. In other situations the sender may have access to multiple
sources of data with conflicting information so the sender should always
be prepared to use the most recent and reliable source of information.
But in absence of any information at all, the sender have to fallback to
default configuration settings.

It would thus improve the situation if CAs, especially enterprise CAs,
that knows or even have the capability to dictate the capabilities of
users, could include the PKCS#9 SMIMECapabilities attribute in
certificates.

One such solution is in practical use since quite some time now.
Both Microsoft CAs and e-mail clients have since long the capabilities
to include and extract users SMIME Capabilities in certificates using
this PKCS#9 attribute as a certificate extension.

This work item should hopefully therefore be a rather simple to conclude
since the PKCS#9 attribute is already defined and used in SMIME for this
purpose, and one way of using this attribute in certificates is already
in widespread use.

I will, given that the WG accepts this work item, volunteer to write the
first draft.

/Stefan Santesson

------_=_NextPart_001_01C4527F.C753D126
Content-Type: application/msword;
	name="SMIME Charter_SMIMECap_changes.doc"
Content-Transfer-Encoding: base64
Content-Description: SMIME Charter_SMIMECap_changes.doc
Content-Disposition: attachment;
	filename="SMIME Charter_SMIMECap_changes.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKwAAAAAAAAAA
EAAALQAAAAEAAAD+////AAAAACwAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////8BAAAA/v///wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAP7/////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------_=_NextPart_001_01C4527F.C753D126--

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, smime mailing list <[email-masked]>, smime chair <[email-masked]>, smime chair <[email-masked]>
Subject: Protocol Action: 'S/MIME Version 3.1 Certificate Handling' to  Proposed Standard 
Date: Mon, 14 Jun 2004 15:59:50 -0400
Sender: [email-masked]

The IESG has approved the following document:

- 'S/MIME Version 3.1 Certificate Handling '
   <draft-ietf-smime-rfc2632bis-07.txt> as a Proposed Standard

This document is the product of the S/MIME Mail Security Working Group. 

The IESG contact persons are Russ Housley and Steve Bellovin.

Technical Summary

  This document specifies conventions for X.509 certificate usage by
  S/MIME (Secure/Multipurpose Internet Mail Extensions) agents.  S/MIME
  provides a method to send and receive secure MIME messages, and
  certificates are an integral part of S/MIME agent processing.  S/MIME
  agents validate certificates as described in RFC 3280, the Internet
  X.509 Public Key Infrastructure Certificate and CRL Profile.  S/MIME
  agents must meet the certificate processing requirements in this
  document as well as those in RFC 3280.

Working Group Summary

  The S/MIME Working Group came to rough consensus on this document.

Protocol Quality

  This document was reviewed by Russ Housley for the IESG.

RFC Editor Note

  Please make the following changes in order to insert an appropriate
  reference to the ASN.1 specification.  Also, the definitions of BER
  and DER are deleted since they are not used in the body of the text.
  Finally, the [SMIME-MSG] reference is changed to point to the most
  current specification, which is already in the RFC Editor queue.

  1.  Please add a reference to the definition of ASN.1.

  OLD:

  ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.208.

  NEW:

  ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.208
  [X.208-88].

  2.  Please delete the definition of BER and DER.

  OLD:

  BER: Basic Encoding Rules for ASN.1, as defined in ITU-T X.209.

  Certificate: A type that binds an entity's name to a public key with a
  digital signature. This type is defined in the Internet X.509 Public
  Key Infrastructure (PKIX) Certificate and CRL Profile [KEYM]. This
  type also contains the distinguished name of the certificate issuer
  (the signer), an issuer-specific serial number, the issuer's signature
  algorithm identifier, a validity period, and extensions also defined
  in that document.

  Certificate Revocation List (CRL): A type that contains information
  about certificates whose validity an issuer has prematurely revoked.
  The information consists of an issuer name, the time of issue, the
  next scheduled time of issue, a list of certificate serial numbers and
  their associated revocation times, and extensions as defined in
  [KEYM]. The CRL is signed by the issuer. The type intended by this
  specification is the one defined in [KEYM].

  DER: Distinguished Encoding Rules for ASN.1, as defined in ITU-T
  X.690.

  NEW:

  Certificate: A type that binds an entity's name to a public key with a
  digital signature. This type is defined in the Internet X.509 Public
  Key Infrastructure (PKIX) Certificate and CRL Profile [KEYM]. This
  type also contains the distinguished name of the certificate issuer
  (the signer), an issuer-specific serial number, the issuer's signature
  algorithm identifier, a validity period, and extensions also defined
  in that document.

  Certificate Revocation List (CRL): A type that contains information
  about certificates whose validity an issuer has prematurely revoked.
  The information consists of an issuer name, the time of issue, the
  next scheduled time of issue, a list of certificate serial numbers and
  their associated revocation times, and extensions as defined in
  [KEYM]. The CRL is signed by the issuer. The type intended by this
  specification is the one defined in [KEYM].

  3.  Please insert a normative reference to the ASN.1 specification.

  OLD:

  [SMIME-MSG] "S/MIME Version 3 Message Specification ", Internet Draft
  draft-ietf-smime-msg

  NEW:

  [SMIME-MSG] "S/MIME Version 3.1 Message Specification ", Internet Draft
  draft-ietf-smime-rfc2633bis-09

  [X.208-88] ITU-T. Recommendation X.208: Specification of Abstract 
  Syntax Notation One (ASN.1). 1988.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Anti-spam news article
Date: Thu, 10 Jun 2004 01:16:36 +1200
Sender: [email-masked]

Russ Housley <[email-masked]> writes:

>This news article will be of interest to members of this IETF mail list.

Probably off-topic, but I just have to add my $0.02: This was debated on the
cryptography list a week or two back, and before that in another forum, the
general feeling ranged from it being almost completely ineffective through to
marginally effective, and nothing like the optimistic:

  Once rolled out, e-mail authentication is "going to have a major impact" on
  spam, says Miles Libbey, antispam product manager for Yahoo Mail. "That's
  not to say the spammers won't adapt...but it's a critical thing to have in
  place."

in the article.  The protocols mentioned in the article are all some variant
on the "build a big wall around the Internet and only let the good guys in",
which will never work because the Internet doesn't contain any definable
inside and outside, only 800 million Manchurian candidates waiting to
activate.  For example MessageLabs recently reported that *two thirds* of all
the spam it blocks is from infected PCs, with much of it coming from
ADSL/cable modem IP pools.  Given that these "spammers" are legitimate users,
no amount of crypto will solve the problem.  I did a talk on this at the
AusCert 2004 conference where I claimed that various protocols designed to
enforce this (Designated Mailers Protocol, Reverse Mail Exchanger, Sender
Permitted From, etc etc) will buy at most 6-12 months, and the only dissent I
got was from an anti-virus researcher who said it'd buy weeks and not months.

See the cryptography list archives and
http://www.cs.auckland.ac.nz/~pgut001/pubs/dammit.pdf for more on this.

Peter.

Date: Wed, 09 Jun 2004 08:28:07 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Anti-spam news article
Sender: [email-masked]

This news article will be of interest to members of this IETF mail list.

Russ

---

Subject: No More Spam From Fakes
Web Titans Seek Standard To Authenticate Senders And Thwart Junk E-Mail

By RIVA RICHMOND
DOW JONES NEWSWIRES
June 9, 2004; Page D9

NEW YORK -- Names just don't have the value they used to -- at least
when it comes to e-mail.

After all, spammers, virus writers and identity thieves now regularly
affix fake names to their e-mail messages in hopes of conning users
into opening them and evading block lists. Take a message today from
"Sonia Sauders," subject line "Re: Hey cutie." It could have been a
note from a college chum, but was actually a pitch for porn. With
billions of these messages cluttering e-mail in boxes every day,
there's simply no trusting a name anymore.

But this could change soon, if Internet heavyweights such as Microsoft
Corp., Yahoo Inc., Time Warner Inc.'s America Online unit and EarthLink
Inc. have their way. These otherwise fierce rivals are working together
to come up with standard technologies for authenticating e-mail
senders, which the companies say will make it easier for mail
recipients to beat back spam, scams and viruses.

Internet service and Web e-mail providers and others in the industry
say broad agreement on a technology is vital to getting the large-scale
adoption that's needed to stop e-mail "spoofing," as the use of fake
sender names is known. The companies are looking at new technology that
could be adopted in the coming months. These include easy and cheap
technologies for verifying e-mail senders' domain names, as well as
more effective, but also more complicated and expensive, systems for
attaching and viewing actual proof of e-mail senders' identities.

Once rolled out, e-mail authentication is "going to have a major
impact" on spam, says Miles Libbey, antispam product manager for Yahoo
Mail. "That's not to say the spammers won't adapt...but it's a critical
thing to have in place."

Internet companies, inundated by customer complaints about e-mail
blights, say authentication would help them clean up in boxes because
real names could be separated out -- and questionable names singled out
for blocking or special scrutiny. It would also help them track down
and prosecute e-mail's abusers.

The simplest authentication approach is being promoted aggressively by
Microsoft and AOL. In this type of system, a receiving e-mail server
attempts to verify whether the domain name in a sender's e-mail address
comes from an authorized computer. This is done by dispatching a quick
query to the computers that hold the central records for Internet
addresses, known as the Domain Name System, to check whether the domain
name and the numerical "IP address" generated by the computer go
together.

Both DNS records and IP addresses are difficult to spoof, but experts
warn that miscreants could get around such "IP-based" systems, at least
in the early stages of adoption, by using e-mail servers that don't
publish their identities in the DNS record. Also, an IP-based system
wouldn't work in all situations, such as with forwarded messages.

Two IP-based proposals have been under consideration: Microsoft's
Caller ID, and Sender Policy Framework, or SPF, which has been
championed by AOL. SPF was created by Meng Wong, the co-founder of
Pobox.com, an e-mail forwarding service owned by IC Group of
Philadelphia.

In late May, Microsoft and Mr. Wong agreed to merge their proposals,
which industry players say will likely pave the way for quick industry
adoption. Although some experts had seen implementation as a year or
two away, Microsoft expects a merged technology to be finalized this
month and says it could be taken up by big ISPs "several months" later.
The technology will be made available for free, Microsoft says.

Both Microsoft and AOL say they would like to see a more-advanced,
key-based system implemented, too, but believe that should be step No.
2.

In key-based systems, cryptographic keys and digital signatures are
used by the sending e-mail server to assert the sender's identity and
by the receiving server to confirm that identity. Big industry players
are most interested in a key-based technology developed by Yahoo called
DomainKeys, which authenticates the domain name in e-mail headers.

Yahoo's Mr. Libbey says that adopting an IP-based system would be a
positive step, but that DomainKeys solves the e-mail authentication
problem better, in large part because it works in cases such as
forwarded messages. DomainKeys, which involves changing how both
outbound and inbound e-mails are processed, will be open-source and
royalty-free.

There are other key-based options, too. Tumbleweed Communications
Corp., an e-mail security company, is advocating the use of its S/MIME,
a protocol already in use for encryption of messages.

Tumbleweed Chief Executive Jeff Smith says there's a lot of
misunderstanding about S/MIME, because it was created as a desktop
encryption technology. He argues it's also simple and cost-effective to
use as a gateway authentication technology, and that its quality
advantages make it the best choice. Tumbleweed would like to work with
Yahoo to merge their technologies.

Yahoo plans to begin using DomainKeys on its own network this year, and
says it's working with others in the industry to advance DomainKeys'
adoption, including Sendmail and Qmail, two popular open-source e-mail
server software programs. Sendmail Inc., which implements e-mail
systems, last week said it would sponsor public testing of both
DomainKeys and the merged Caller-ID/SPF technology when it becomes
available.

But all the giants on the front lines of the war on spam warn against
false hopes that authentication will eliminate e-mail woes or bring
peace.

"Like bad colds and taxes, spam in some way or form will always be
lurking around," says AOL spokesman Nicholas J. Graham. Spammers are
resilient and tenacious, but "we are hopeful that [authentication
technology] will meet the test, that it will take a very large chunk of
spammers out of the game."

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc2632bis-07.txt
Date: Fri, 04 Jun 2004 16:19:42 -0400
Sender: [email-masked]

--NextPart

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

	Title		: S/MIME Version 3.1 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2632bis-07.txt
	Pages		: 13
	Date		: 2004-6-4
	
This document specifies conventions for X.509 certificate usage by
S/MIME (Secure/Multipurpose Internet Mail Extensions) agents. S/MIME
provides a method to send and receive secure MIME messages, and
certificates are an integral part of S/MIME agent processing. S/MIME
agents validate certificates as described in RFC 3280, the Internet
X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME
agents must meet the certificate processing requirements in this
document as well as those in RFC 3280.
This specification is compatible with the Cryptographic Message Syntax
[CMS] in that it uses the data types defined by CMS. It also inherits
all the varieties of architectures for certificate-based key
management supported by CMS.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-rfc2632bis-07.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc2632bis-07.txt

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

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

--OtherAccess--

--NextPart--