Get $200 bonus at our Casino!

["Lilian G. Henderson" <[e-mail]>]

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




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5RKmhTf081661; Sun, 27 Jun 2004 13:48:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5RKmhra081660; Sun, 27 Jun 2004 13:48:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fledermaus.treasury.govt.nz ([202.36.173.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5RKmfcG081652 for <[e-mail]>; Sun, 27 Jun 2004 13:48:42 -0700 (PDT) (envelope-from [e-mail])
Received: from juliet.hamlet.treasury.govt.nz (Not Verified[172.20.2.43]) by fledermaus.treasury.govt.nz with Non-Descript e-mail server id <B0001ae240>; Mon, 28 Jun 2004 08:48:36 +1200
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Mon, 28 Jun 2004 08:48:36 +1200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Anti-spam news article / S/MIME Gateways
Thread-Index: AcRZKGy4wWin4/4dQd66hE5/ARigdgA6asxAAAaAWwA=
From: "Craig McGregor" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, "Ben Littauer" <[e-mail]>, <[e-mail]>
content-class: urn:content-classes:message
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5RKmgcG081655
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>

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: [e-mail]
> [mailto:[e-mail]] On Behalf Of Trevor Freeman
> Sent: Friday, 25 June 2004 5:42 a.m.
> To: Ben Littauer; [e-mail]
> 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: [e-mail]
> [mailto:[e-mail]]
> * On Behalf Of Ben Littauer
> * Sent: Wednesday, June 23, 2004 6:34 AM
> * To: [e-mail]
> * 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" <[e-mail]>
> * > Date: Tue, 22 Jun 2004 11:15:39 -0700
> * > To: "Craig McGregor" <[e-mail]>, 
> "Russ Housley"
> * > <[e-mail]>, <[e-mail]>
> * > 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: [e-mail]
> * > [mailto:[e-mail]]
> * > * On Behalf Of Craig McGregor
> * > * Sent: Monday, June 21, 2004 8:12 PM
> * > * To: Russ Housley; [e-mail]
> * > * 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.
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * >
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PGhkfE090719; Fri, 25 Jun 2004 09:43:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PGhjqY090718; Fri, 25 Jun 2004 09:43:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PGhjX7090711 for <[e-mail]>; Fri, 25 Jun 2004 09:43:45 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i5PGhl1p024646; Fri, 25 Jun 2004 09:43:48 -0700 (PDT)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <NQPCBY69>; Fri, 25 Jun 2004 09:43:47 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: Anti-spam news article / S/MIME Gateways
Date: Fri, 25 Jun 2004 09:43:41 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
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>

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:[e-mail]]
Sent:	Fri Jun 25 08:03:32 2004
To:	Hallam-Baker, Phillip
Cc:	[e-mail]
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 "*@foo.com" gateway certs, [e-mail]
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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PG7fnZ088139; Fri, 25 Jun 2004 09:07:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PG7fhh088138; Fri, 25 Jun 2004 09:07:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PG7efZ088132 for <[e-mail]>; Fri, 25 Jun 2004 09:07:40 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i5PG7gXs022984; Fri, 25 Jun 2004 09:07:42 -0700 (PDT)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <NQRFPWHQ>; Fri, 25 Jun 2004 09:07:42 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, "'Ben Littauer'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Fri, 25 Jun 2004 09:07:34 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
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>

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:[e-mail]]
Sent:	Fri Jun 25 07:45:20 2004
To:	Hallam-Baker, Phillip; Ben Littauer; [e-mail]
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:[e-mail]]
* Sent: Thursday, June 24, 2004 9:44 PM
* To: Trevor Freeman; Ben Littauer; [e-mail]
* 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: [e-mail]
* > [mailto:[e-mail]]On Behalf Of Trevor Freeman
* > Sent: Thursday, June 24, 2004 1:42 PM
* > To: Ben Littauer; [e-mail]
* > 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: [e-mail]
* > [mailto:[e-mail]]
* > * On Behalf Of Ben Littauer
* > * Sent: Wednesday, June 23, 2004 6:34 AM
* > * To: [e-mail]
* > * 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" <[e-mail]>
* > * > Date: Tue, 22 Jun 2004 11:15:39 -0700
* > * > To: "Craig McGregor" <[e-mail]>, "Russ
* > Housley"
* > * > <[e-mail]>, <[e-mail]>
* > * > 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: [e-mail]
* > * > [mailto:[e-mail]]
* > * > * On Behalf Of Craig McGregor
* > * > * Sent: Monday, June 21, 2004 8:12 PM
* > * > * To: Russ Housley; [e-mail]
* > * > * 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.
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * >
* >
* >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PEjHbf081060; Fri, 25 Jun 2004 07:45:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PEjH76081059; Fri, 25 Jun 2004 07:45:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PEjGl4081052 for <[e-mail]>; Fri, 25 Jun 2004 07:45:16 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 25 Jun 2004 07:45:18 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 25 Jun 2004 07:45:18 -0700
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Jun 2004 07:45:18 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 07:45:19 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Fri, 25 Jun 2004 07:45:09 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Anti-spam news article / S/MIME Gateways
Thread-Index: AcRabwzDCFOKxN9FSR2Q9W4Wq8zjRwAU1neg
From: "Trevor Freeman" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, "Ben Littauer" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 25 Jun 2004 14:45:19.0234 (UTC) FILETIME=[092DDE20:01C45AC3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5PEjGl4081053
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 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:[e-mail]]
* Sent: Thursday, June 24, 2004 9:44 PM
* To: Trevor Freeman; Ben Littauer; [e-mail]
* 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: [e-mail]
* > [mailto:[e-mail]]On Behalf Of Trevor Freeman
* > Sent: Thursday, June 24, 2004 1:42 PM
* > To: Ben Littauer; [e-mail]
* > 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: [e-mail]
* > [mailto:[e-mail]]
* > * On Behalf Of Ben Littauer
* > * Sent: Wednesday, June 23, 2004 6:34 AM
* > * To: [e-mail]
* > * 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" <[e-mail]>
* > * > Date: Tue, 22 Jun 2004 11:15:39 -0700
* > * > To: "Craig McGregor" <[e-mail]>, "Russ
* > Housley"
* > * > <[e-mail]>, <[e-mail]>
* > * > 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: [e-mail]
* > * > [mailto:[e-mail]]
* > * > * On Behalf Of Craig McGregor
* > * > * Sent: Monday, June 21, 2004 8:12 PM
* > * > * To: Russ Housley; [e-mail]
* > * > * 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.
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * > *
* > * >
* >
* >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PDCLEE072419; Fri, 25 Jun 2004 06:12:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PDCLDQ072418; Fri, 25 Jun 2004 06:12:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PDCK1V072399 for <[e-mail]>; Fri, 25 Jun 2004 06:12:21 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 25 Jun 2004 09:12:03 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <[e-mail]>
CC: [e-mail]
Subject: Re: Anti-spam news article / S/MIME Gateways
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Jun 2004 13:12:09.0545 (UTC) FILETIME=[05770390:01C45AB6]
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>

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 "*@foo.com" gateway certs, [e-mail]
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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P4i8RL037052; Thu, 24 Jun 2004 21:44:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P4i83M037051; Thu, 24 Jun 2004 21:44:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P4i7Vj037045 for <[e-mail]>; Thu, 24 Jun 2004 21:44:07 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i5P4iDgZ027975; Thu, 24 Jun 2004 21:44:13 -0700 (PDT)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <NQRFNYKS>; Thu, 24 Jun 2004 21:44:13 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, Ben Littauer <[e-mail]>, [e-mail]
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Thu, 24 Jun 2004 21:44:12 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
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>

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: [e-mail]
> [mailto:[e-mail]]On Behalf Of Trevor Freeman
> Sent: Thursday, June 24, 2004 1:42 PM
> To: Ben Littauer; [e-mail]
> 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: [e-mail]
> [mailto:[e-mail]]
> * On Behalf Of Ben Littauer
> * Sent: Wednesday, June 23, 2004 6:34 AM
> * To: [e-mail]
> * 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" <[e-mail]>
> * > Date: Tue, 22 Jun 2004 11:15:39 -0700
> * > To: "Craig McGregor" <[e-mail]>, "Russ
> Housley"
> * > <[e-mail]>, <[e-mail]>
> * > 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: [e-mail]
> * > [mailto:[e-mail]]
> * > * On Behalf Of Craig McGregor
> * > * Sent: Monday, June 21, 2004 8:12 PM
> * > * To: Russ Housley; [e-mail]
> * > * 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.
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * >
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P0Kxqv016319; Thu, 24 Jun 2004 17:20:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P0KxCn016318; Thu, 24 Jun 2004 17:20:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P0Kw38016312 for <[e-mail]>; Thu, 24 Jun 2004 17:20:58 -0700 (PDT) (envelope-from [e-mail])
Received: from 146-115-115-31.c3-0.lex-ubr2.sbo-lex.ma.cable.rcn.com ([146.115.115.31] helo=[192.168.2.164]) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.35 #7) id 1BdeSl-0000oJ-00 for [e-mail]; Thu, 24 Jun 2004 20:21:03 -0400
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Thu, 24 Jun 2004 20:21:34 -0400
Subject: Re: Anti-spam news article / S/MIME Gateways
From: Ben Littauer <[e-mail]>
To: <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
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>

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" <[e-mail]>
> Date: Thu, 24 Jun 2004 10:42:01 -0700
> To: "Ben Littauer" <[e-mail]>, <[e-mail]>
> 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: [e-mail]
> [mailto:[e-mail]]
> * On Behalf Of Ben Littauer
> * Sent: Wednesday, June 23, 2004 6:34 AM
> * To: [e-mail]
> * 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" <[e-mail]>
> * > Date: Tue, 22 Jun 2004 11:15:39 -0700
> * > To: "Craig McGregor" <[e-mail]>, "Russ
> Housley"
> * > <[e-mail]>, <[e-mail]>
> * > 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: [e-mail]
> * > [mailto:[e-mail]]
> * > * On Behalf Of Craig McGregor
> * > * Sent: Monday, June 21, 2004 8:12 PM
> * > * To: Russ Housley; [e-mail]
> * > * 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.
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * > *
> * >
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHg08b079148; Thu, 24 Jun 2004 10:42:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OHg0KV079146; Thu, 24 Jun 2004 10:42:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHfxKc079137 for <[e-mail]>; Thu, 24 Jun 2004 10:41:59 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 24 Jun 2004 10:42:03 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 24 Jun 2004 10:42:03 -0700
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jun 2004 10:42:02 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 10:42:02 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Thu, 24 Jun 2004 10:42:01 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Anti-spam news article / S/MIME Gateways
Thread-Index: AcRZKGy4wWin4/4dQd66hE5/ARigdgA6asxA
From: "Trevor Freeman" <[e-mail]>
To: "Ben Littauer" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 24 Jun 2004 17:42:02.0737 (UTC) FILETIME=[8EF24610:01C45A12]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5OHfxKc079138
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 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: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Ben Littauer
* Sent: Wednesday, June 23, 2004 6:34 AM
* To: [e-mail]
* 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" <[e-mail]>
* > Date: Tue, 22 Jun 2004 11:15:39 -0700
* > To: "Craig McGregor" <[e-mail]>, "Russ
Housley"
* > <[e-mail]>, <[e-mail]>
* > 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: [e-mail]
* > [mailto:[e-mail]]
* > * On Behalf Of Craig McGregor
* > * Sent: Monday, June 21, 2004 8:12 PM
* > * To: Russ Housley; [e-mail]
* > * 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.
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NLlrCb088118; Wed, 23 Jun 2004 14:47:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NLlrmE088117; Wed, 23 Jun 2004 14:47:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NLlqtl088110 for <[e-mail]>; Wed, 23 Jun 2004 14:47:52 -0700 (PDT) (envelope-from [e-mail])
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1BdFYN-0003KW-89; Wed, 23 Jun 2004 17:45:11 -0400
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: 'Use of the SEED Encryption Algorithm in CMS' to Proposed  Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 23 Jun 2004 17:45:11 -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>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NIOWPd045911; Wed, 23 Jun 2004 11:24:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NIOWw9045910; Wed, 23 Jun 2004 11:24:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5NIOVbU045903 for <[e-mail]>; Wed, 23 Jun 2004 11:24:31 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 20792 invoked by uid 0); 23 Jun 2004 18:24:15 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.169.145) by woodstock.binhost.com with SMTP; 23 Jun 2004 18:24:15 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Wed, 23 Jun 2004 14:24:35 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Content Collection
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>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NDXVZK086179; Wed, 23 Jun 2004 06:33:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NDXVWu086178; Wed, 23 Jun 2004 06:33:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NDXUAg086172 for <[e-mail]>; Wed, 23 Jun 2004 06:33:30 -0700 (PDT) (envelope-from [e-mail])
Received: from 146-115-115-31.c3-0.lex-ubr2.sbo-lex.ma.cable.rcn.com ([146.115.115.31] helo=[192.168.2.164]) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.35 #7) id 1Bd7sW-0005Gq-00 for [e-mail]; Wed, 23 Jun 2004 09:33:28 -0400
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Wed, 23 Jun 2004 09:34:06 -0400
Subject: Re: Anti-spam news article / S/MIME Gateways
From: Ben Littauer <[e-mail]>
To: <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
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>

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" <[e-mail]>
> Date: Tue, 22 Jun 2004 11:15:39 -0700
> To: "Craig McGregor" <[e-mail]>, "Russ Housley"
> <[e-mail]>, <[e-mail]>
> 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: [e-mail]
> [mailto:[e-mail]]
> * On Behalf Of Craig McGregor
> * Sent: Monday, June 21, 2004 8:12 PM
> * To: Russ Housley; [e-mail]
> * 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.
> * 
> * 
> * 
> * 
> * 
> * 
> * 
> * 
> * 
> * 
> * 
> * 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MIFbX9084228; Tue, 22 Jun 2004 11:15:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MIFbpq084227; Tue, 22 Jun 2004 11:15:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MIFbFL084221 for <[e-mail]>; Tue, 22 Jun 2004 11:15:37 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 22 Jun 2004 11:15:40 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 22 Jun 2004 11:15:40 -0700
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Jun 2004 11:15:40 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 22 Jun 2004 11:16:04 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Tue, 22 Jun 2004 11:15:39 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Anti-spam news article / S/MIME Gateways
Thread-Index: AcROJMpZpnZRpmhFReyXbbbXUgTQ8gJzUPsgACR6MSA=
From: "Trevor Freeman" <[e-mail]>
To: "Craig McGregor" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 22 Jun 2004 18:16:04.0353 (UTC) FILETIME=[FB04A710:01C45884]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5MIFbFL084222
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 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: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Craig McGregor
* Sent: Monday, June 21, 2004 8:12 PM
* To: Russ Housley; [e-mail]
* 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.
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MIDgl0083885; Tue, 22 Jun 2004 11:13:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MIDgU5083884; Tue, 22 Jun 2004 11:13:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MIDfXE083876 for <[e-mail]>; Tue, 22 Jun 2004 11:13:41 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i5MIDhda000984; Tue, 22 Jun 2004 11:13:44 -0700 (PDT)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <KM09HCNV>; Tue, 22 Jun 2004 11:13:43 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Craig McGregor'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Tue, 22 Jun 2004 11:13:41 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
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>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MI8JNk082839; Tue, 22 Jun 2004 11:08:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MI8JM1082835; Tue, 22 Jun 2004 11:08:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vahqex2.digitalnet.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MI8Hrh082800; Tue, 22 Jun 2004 11:08:17 -0700 (PDT) (envelope-from [e-mail])
Received: from [158.189.2.56] ([158.189.2.56]) by vahqex2.digitalnet.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Jun 2004 14:08:20 -0400
Message-ID: <[e-mail]>
Date: Tue, 22 Jun 2004 14:08:18 -0400
From: Matt Bertapelle <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: imc-sfl <[e-mail]>, [e-mail]
Subject: v2.4 S/MIME Freeware Library (SFL) Now Available
Content-Type: multipart/alternative; boundary="------------030905080900040904080104"
X-OriginalArrivalTime: 22 Jun 2004 18:08:20.0789 (UTC) FILETIME=[E6B66650:01C45883]
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 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--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M3CIvI025260; Mon, 21 Jun 2004 20:12:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5M3CIla025259; Mon, 21 Jun 2004 20:12:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fledermaus.treasury.govt.nz ([202.36.173.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M3CG2S025224 for <[e-mail]>; Mon, 21 Jun 2004 20:12:17 -0700 (PDT) (envelope-from [e-mail])
Received: from juliet.hamlet.treasury.govt.nz (Not Verified[172.20.2.43]) by fledermaus.treasury.govt.nz with Non-Descript e-mail server id <B0001a8abd>; Tue, 22 Jun 2004 15:12:14 +1200
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Subject: RE: Anti-spam news article / S/MIME Gateways
Date: Tue, 22 Jun 2004 15:12:14 +1200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Anti-spam news article / S/MIME Gateways
Thread-Index: AcROJMpZpnZRpmhFReyXbbbXUgTQ8gJzUPsg
From: "Craig McGregor" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
content-class: urn:content-classes:message
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5M3CH2S025252
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>

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















Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IFFtw9011289; Fri, 18 Jun 2004 08:15:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IFFta3011288; Fri, 18 Jun 2004 08:15:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IFFrtO011247 for <[e-mail]>; Fri, 18 Jun 2004 08:15:54 -0700 (PDT) (envelope-from [e-mail])
Received: from eur-imc-02.europe.corp.microsoft.com ([65.53.196.43]) by mail-eur.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 18 Jun 2004 16:15:46 +0100
Received: from 65.53.196.43 by eur-imc-02.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 18 Jun 2004 16:15:46 +0100
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by eur-imc-02.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 18 Jun 2004 16:15:46 +0100
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SMIME Capabilities in X.509 Certificates
Date: Fri, 18 Jun 2004 16:14:56 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SMIME Capabilities in X.509 Certificates
Thread-Index: AcRU7BZ2DulBo3OyQ2eYHymfJRpJPgAWe/Zw
From: "Stefan Santesson" <[e-mail]>
To: "Blake Ramsdell" <[e-mail]>, "smime mailing list" <[e-mail]>
Cc: "smime chair" <[e-mail]>, "smime chair" <[e-mail]>
X-OriginalArrivalTime: 18 Jun 2004 15:15:46.0610 (UTC) FILETIME=[217D1120:01C45547]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5IFFstO011283
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,

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




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I4NsYZ086149; Thu, 17 Jun 2004 21:23:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5I4NsnY086148; Thu, 17 Jun 2004 21:23:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I4NsAQ086121 for <[e-mail]>; Thu, 17 Jun 2004 21:23:54 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ; Thu, 17 Jun 2004 21:23:53 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'smime mailing list'" <[e-mail]>
Cc: "'smime chair'" <[e-mail]>, "'smime chair'" <[e-mail]>
Subject: RE: SMIME Capabilities in X.509 Certificates
Date: Thu, 17 Jun 2004 21:23:53 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[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.2800.1409
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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GJZi0q042650; Wed, 16 Jun 2004 12:35:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GJZiCN042648; Wed, 16 Jun 2004 12:35:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GJZhaS042641 for <[e-mail]>; Wed, 16 Jun 2004 12:35:43 -0700 (PDT) (envelope-from [e-mail])
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Bafzu-00014X-9X; Wed, 16 Jun 2004 15:22:58 -0400
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, smime mailing list <[e-mail]>, smime chair <[e-mail]>, smime chair <[e-mail]>
Subject: Protocol Action: 'Cryptographic Message Syntax (CMS)' to  Proposed Standard 
Message-Id: <[e-mail]>
Date: Wed, 16 Jun 2004 15:22:58 -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>

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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F2Nmff082953; Mon, 14 Jun 2004 19:23:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F2NmE5082952; Mon, 14 Jun 2004 19:23:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F2Nl3A082907 for <[e-mail]>; Mon, 14 Jun 2004 19:23:47 -0700 (PDT) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.22]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jun 2004 03:23:44 +0100
Received: from 65.53.196.22 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 15 Jun 2004 03:23:44 +0100
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jun 2004 03:23:43 +0100
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4527F.C753D126"
Subject: SMIME Capabilities in X.509 Certificates
Date: Tue, 15 Jun 2004 03:23:44 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: SMIME Capabilities in X.509 Certificates
Thread-Index: AcRSXSJDwCa9S0eORoGBWf3ztt7ORwAHu9eA
From: "Stefan Santesson" <[e-mail]>
To: "smime mailing list" <[e-mail]>
Cc: "smime chair" <[e-mail]>, "smime chair" <[e-mail]>
X-OriginalArrivalTime: 15 Jun 2004 02:23:43.0937 (UTC) FILETIME=[C7C8DB10:01C4527F]
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 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/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAW0AJBAAA8BK/AAAAAAAAEAAAAAAABgAA8hEAAA4AYmpiajQDNAMAAAAAAAAAAAAAAAAAAAAA
AAAJBBYALhoAAFZpAQBWaQEA8gkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAAHwBAAAAAAAAfAEAAHwB
AAAAAAAAfAEAAAAAAAB8AQAAAAAAAHwBAAAAAAAAfAEAABQAAAAAAAAAAAAAAJABAAAAAAAAWAIA
AAAAAABYAgAAAAAAAFgCAAAAAAAAWAIAABQAAABsAgAADAAAAJABAAAAAAAAAwQAACwBAACEAgAA
AAAAAIQCAAAAAAAAhAIAAAAAAACEAgAAAAAAAIQCAAAAAAAAhAIAAAAAAACEAgAAAAAAAIQCAAAA
AAAAQgMAAAIAAABEAwAAAAAAAEQDAAAAAAAARAMAAAAAAABEAwAAAAAAAEQDAAAAAAAARAMAACQA
AAAvBQAAUgIAAIEHAAC4AAAAaAMAABUAAAAAAAAAAAAAAAAAAAAAAAAAfAEAAAAAAACEAgAAAAAA
AAAAAAAAAAAAAAAAAAAAAACEAgAAAAAAAIQCAAAAAAAAhAIAAAAAAACEAgAAAAAAAGgDAAAAAAAA
AAAAAAAAAAB8AQAAAAAAAHwBAAAAAAAAhAIAAAAAAAAAAAAAAAAAAIQCAAAAAAAAfQMAAD4AAADo
AgAAAAAAAOgCAAAAAAAA6AIAAAAAAACEAgAALgAAAHwBAAAAAAAAhAIAAAAAAAB8AQAAAAAAAIQC
AAAAAAAAQgMAAAAAAAAAAAAAAAAAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAhAIAAAAAAABCAwAAAAAAAOgCAAAiAAAA6AIAAAAAAAAAAAAA
AAAAAAoDAAAAAAAAfAEAAAAAAAB8AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgMAAAAAAACEAgAAAAAAAHgCAAAMAAAAcFcOOiFP
xAEAAAAAAAAAAFgCAAAAAAAAsgIAABYAAAAKAwAAAAAAAAAAAAAAAAAAQgMAAAAAAAC7AwAASAAA
AAMEAAAAAAAACgMAAAAAAAA5CAAAAAAAAMgCAAAKAAAAOQgAAAAAAAAKAwAAAAAAAAAAAAAAAAAA
kAEAAAAAAACQAQAAAAAAAHwBAAAAAAAAfAEAAAAAAAB8AQAAAAAAAHwBAAAAAAAAAAAAAAAAAAAA
AAAAAAAAADkIAAAAAAAAAAAAAAAAAAB8AQAAAAAAAAoDAAA4AAAAhAIAAAAAAACEAgAAAAAAAOgC
AAAAAAAAhAIAAAAAAACEAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhAIA
AAAAAACEAgAAAAAAAIQCAAAAAAAAaAMAAAAAAABoAwAAAAAAAJABAAAAAAAAkAEAAGQAAAD0AQAA
ZAAAAAAAAAAAAAAA0gIAABYAAACQAQAAAAAAAJABAAAAAAAA9AEAAAAAAAACAAEBAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFRoZSBT
L01JTUUgV29ya2luZyBHcm91cCBoYXMgY29tcGxldGVkIGEgc2VyaWVzIG9mIFByb3Bvc2VkC1N0
YW5kYXJkcyB0aGF0IGNvbXByaXNlIHRoZSBTL01JTUUgdmVyc2lvbiAzIHNwZWNpZmljYXRpb24u
C0N1cnJlbnQgZWZmb3J0cyB1cGRhdGUgYW5kIGJ1aWxkIHVwb24gdGhlc2UgYmFzZSBzcGVjaWZp
Y2F0aW9ucy4LC1RoZSBDcnlwdG9ncmFwaGljIE1lc3NhZ2UgU3ludGF4IChDTVMpIChSRkMgMzM2
OSkgaXMgY3J5cHRvZ3JhcGhpYwthbGdvcml0aG0gaW5kZXBlbmRlbnQsIHlldCB0aGVyZSBpcyBh
bHdheXMgbW9yZSB0aGFuIG9uZSB3YXkgdG8LdXNlIGFueSBhbGdvcml0aG0uIFRvIGVuc3VyZSBp
bnRlcm9wZXJhYmlsaXR5LCBlYWNoIGFsZ29yaXRobQtzaG91bGQgaGF2ZSBhIHNwZWNpZmljYXRp
b24gdGhhdCBkZXNjcmliZXMgaXRzIHVzZSB3aXRoIENNUy4LU3BlY2lmaWNhdGlvbnMgZm9yIHRo
ZSB1c2Ugb2YgYWRkaXRpb25hbCBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMLd2lsbCBiZSBkZXZl
bG9wZWQuCwtBcyBwYXJ0IG9mIHRoZSBzcGVjaWZpY2F0aW9uIHVwZGF0ZSwgYSBuZXcgc3VpdGUg
b2YgIm1hbmRhdG9yeQt0byBpbXBsZW1lbnQiIGFsZ29yaXRobXMgd2lsbCBiZSBzZWxlY3RlZC4g
VGhlc2UgYWxnb3JpdGhtcyB3aWxsC2JlIHJlZmxlY3RlZCBpbiB1cGRhdGVzIHRvIENFUlQgYW5k
IE1TRyAoUkZDIDI2MzIgYW5kIFJGQyAyNjMzKS4LQnVpbGRpbmcgb24gdGhlIENNUyBDb21wcmVz
c2VkRGF0YSBjb250ZW50IHR5cGUgc3BlY2lmaWVkIGluC1JGQyAzMjc0LCB0aGUgdXBkYXRlIHRv
IE1TRyB3aWxsIHNwZWNpZnkgY29udmVudGlvbnMgZm9yIG1lc3NhZ2ULY29tcHJlc3Npb24sIGlu
IGFkZGl0aW9uIHRvIG1lc3NhZ2Ugc2lnbmF0dXJlIGFuZCBlbmNyeXB0aW9uLgsLVG8gYWlkIGlt
cGxlbWVudGVycywgZG9jdW1lbnRzIGNvbnRhaW5pbmcgZXhhbXBsZSBvdXRwdXQgZm9yIENNUwt3
aWxsIGJlIGNvbGxlY3RlZCBhbmQgcHVibGlzaGVkLiBTb21lIG9mIHRoZSBleGFtcGxlcyB3aWxs
IGluY2x1ZGULc3RydWN0dXJlcyBhbmQgc2lnbmVkIGF0dHJpYnV0ZXMgZGVmaW5lZCBpbiB0aGUg
RW5oYW5jZWQgU2VjdXJpdHkLU2VydmljZXMgKEVTUykgKFJGQyAyNjM0KSBkb2N1bWVudC4LC0NN
UywgYW5kIHRodXMgUy9NSU1FIHZlcnNpb24gMyBhbmQgbGF0ZXIsIHBlcm1pdCB0aGUgdXNlIG9m
C3ByZXZpb3VzbHkgZGlzdHJpYnV0ZWQgc3ltbWV0cmljIGtleS1lbmNyeXB0aW9uIGtleXMuIFNw
ZWNpZmljYXRpb25zC2ZvciB0aGUgZGlzdHJpYnV0aW9uIG9mIHN5bW1ldHJpYyBrZXktZW5jcnlw
dGlvbiBrZXlzIHRvIG11bHRpcGxlC21lc3NhZ2UgcmVjaXBpZW50cyB3aWxsIGJlIGRldmVsb3Bl
ZC4gTWFpbCBMaXN0IEFnZW50cyAoTUxBcykgYXJlC29uZSB1c2VyIG9mIHN5bW1ldHJpYyBrZXkt
ZW5jcnlwdGlvbiBrZXlzLiBUaGUgc3BlY2lmaWNhdGlvbiB3aWxsIGJlC2FsZ29yaXRobSBpbmRl
cGVuZGVudC4LC0luIFMvTUlNRSB2ZXJzaW9uIDMgYW5kIGxhdGVyLCBDTVMgaXMgdXNlZCB0byBw
cm92aWRlIHNlY3VyaXR5IHRvIHRoZQttZXNzYWdlIGNvbnRlbnQgaWYgb2YgYW4gSW50ZXJuZXQg
bWFpbCBtZXNzYWdlLiBIb3dldmVyLCBDTVMgY2FuIGFsc28LYmUgZW1wbG95ZWQgaW4gYW4gWC40
MDAgZWxlY3Ryb25pYyBtZXNzYWdpbmcgZW52aW9ubWVudHNlbnZpcm9ubWVudHMuC1NwZWNpZmlj
YXRpb25zIHdpbGwgYmUgZGV2ZWxvcGVkIGFsbG93aW5nIHRoaXMgdG8gYmUgZG9uZSBpbiBhbgtp
bnRlcm9wZXJhYmxlIG1hbm5lci4LCw1UbyBhaWQgaW5pdGlhbCBkZXRlcm1pbmF0aW9uIG9mIHJl
Y2lwaWVudJJzIGNyeXB0b2dyYXBoaWMLY2FwYWJpbGl0aWVzIGEgc3BlY2lmaWNhdGlvbiB3aWxs
IGJlIGRldmVsb3BlZCBhbGxvd2luZyBTL01JTUULY2FwYWJpbGl0aWVzIHRvIGJlIHN0b3JlZCBh
bmQgYXNzZXJ0ZWQgaW4gWC41MDkgY2VydGlmaWNhdGVzIGJhc2VkC29uIFJGQyAzMjgwLCB0aGUg
WC41MDkgY2VydGlmaWNhdGUgYW5kIENSTCBwcm9maWxlIGRldmVsb3BlZCBieQt0aGUgUEtJWCBX
b3JraW5nIEdyb3VwLgsNVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBwZXJmb3JtIG5lY2Vzc2FyeSBp
bnRlcm9wZXJhYmlsaXR5IHRlc3RpbmcLdG8gcHJvZ3Jlc3MgdGhlIFMvTUlNRSBzcGVjaWZpY2F0
aW9ucyB0byBEcmFmdCBTdGFuZGFyZC4gVGhlIENNUwtzcGVjaWZpY2F0aW9uIGRlcGVuZHMgb24g
dGhlIFJGQyAzMjgwLCB0aGUgUEtJWCBjZXJ0aWZpY2F0ZSBhbmQgQ1JMC3Byb2ZpbGUuIFRoaXMg
cHJvZmlsZSBtdXN0IHByb2dyZXNzIHRvIERyYWZ0IFN0YW5kYXJkIGJlZm9yZSBDTVMLYW5kIHRo
ZSBvdGhlciBTL01JTUUgc3BlY2lmaWNhdGlvbnMgY2FuIHByb2dyZXNzIHRvIERyYWZ0IFN0YW5k
YXJkLgtBc3N1bWluZyB0aW1lbHkgcHJvZ3Jlc3MgYnkgdGhlIFBLSVggV29ya2luZyBHcm91cCwg
dGhlIFMvTUlNRQtzcGVjaWZpY2F0aW9uIGNhbiBzdGFydCBwcm9ncmVzc2luZyB0byBEcmFmdCBT
dGFuZGFyZCB0b3dhcmQgdGhlC2VuZCBvZiAyMDAzNC4NAAAAAAAAAAAAAAAAAAAABgAALw4AADEO
AAAyDgAAMw4AADUOAABwDgAAcw4AAHQOAAB2DgAAdw4AAJIOAACdDgAAoQ4AAKIOAACpDgAAAQ8A
AAIPAAADDwAALA8AAC0PAAAuDwAAPA8AAL8PAADKDwAA0A8AANUPAADpDwAA6g8AAPEPAAAWEAAA
FxAAABgQAADAEAAA8+Tdzb3zsPPk3fPdvc29893NoJOgk6CTgHCAcIBgoM3zAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAfAQiBBEgCAAVo3FOGhhZocGryAE9KAwBRSgMAXkoDAB8BCIEESAIABWjbU4aG
FmhwavIAT0oDAFFKAwBeSgMAJQEIgQRIAgAFaNtThoYVaBM5VAAWaHBq8gBPSgMAUUoDAF5KAwAZ
AQiBBEgBABZoEzlUAE9KAwBRSgMAXkoDAB8BCIEESAEAFWgTOVQAFmgTOVQAT0oDAFFKAwBeSgMA
GBVoEzlUABZodCgsAE9KAwBRSgMAXkoDAAAfAQiBBEgBABVoEzlUABZo+i2CAE9KAwBRSgMAXkoD
AB8BCIEESAEAFWgTOVQAFmh0KCwAT0oDAFFKAwBeSgMADQAIgRZo+i2CAGNIAQAcAAiBFWj6LYIA
Fmj6LYIAQioGY0gBAHBo/wAAAAAYFWgTOVQAFmj6LYIAT0oDAFFKAwBeSgMAIQAGAAADDwAAGBAA
APIRAAD9AAAAAAAAAAAAAAAAugAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAEMAAEXGgAAAAgDcU4aGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAADAAYAAPIRAAD9AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQHAEAAA5hAAAEIRAABD
EQAA7hEAAO8RAADwEQAA8REAAPIRAADj1sbWqprWjQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYFWgTOVQAFmjcer4AT0oD
AFFKAwBeSgMAAB8BCIEESAIABWjbU4aGFmhwavIAT0oDAFFKAwBeSgMANwAIgRVoEzlUABZo+i2C
ABdocGryAE9KAwBRSgMAXkoDAGNIAgBkaAAAAABkaAAAAABkaNtThoYfAQiBBEgCAAVo3FOGhhZo
cGryAE9KAwBRSgMAXkoDABgVaBM5VAAWaPotggBPSgMAUUoDAF5KAwAANwAIgRVoEzlUABZo+i2C
ABdocGryAE9KAwBRSgMAXkoDAGNIAgBkaAAAAABkaAAAAABkaNxThoYACCwAMZBoAR+wgi4gsMZB
IbBuBCKwbgQjkKUGJJClBiWwAAAXsMQCGLDEAgyQxAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAQABIAAQCcAA8AAwAA
AAAAAAAAAEAAAEDx/wIAQAAMBAAAAAAAAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAYAENKGABfSAEE
YUoYAG1ICQRzSAkEdEgGBAAAAAAAAAAAAAAAAAAAAAAAAEQAQUDy/6EARAAMBQAAAAAAAAAAFgBE
AGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABSAGlA8/+zAFIA
DAUAAAAAAAAAAAwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAcABf2AwAANNYGAAEKA2wANNYG
AAEFAwAAYfYDAAACAAsAAAAoAGtA9P/BACgAAAUAAAAAAAAAAAcATgBvACAATABpAHMAdAAAAAIA
AAAAAAAASACZQAEA8gBIAAwFAABnIW4AAAAMAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0AAAAAgAP
ABQAQ0oQAE9KBABRSgQAXkoEAGFKEAAAAAAA8gkAAAQAABoAAAAA/////wAAAAADBwAAGAgAAPQJ
AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQ
AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAEAAAAAAwcAABgIAAD0CQAAPDsBMAAAAAAAAAAA
AgAAAAEAAAAAAAAAAAAQAQAAAAAFAgAAAAAAAAAAAAAAAAAAAAAAAAAAEAE8OwEwAAAAAAAAAAAB
AAAAAQAAAAAAAAAAAIAHAAYAAMAQAADyEQAACQAAAAwAAAAABgAA8hEAAAoAAAAABgAA8hEAAAsA
AAAAAAAA4wIAAPECAAByBQAAdgUAADUJAABDCQAA9AkAAAcAHAAHABwABwAEAAcAAAAAAGkAAAB2
AAAA9AkAAAcAMwAHAAAAAAD0CQAABwAAAAAANQkAAEMJAAD0CQAABwAEAAcA//8CAAAADABSAHUA
cwBzACAASABvAHUAcwBsAGUAeQAAAAgAAAAEAAAACAAAAOUAAAAAAAAABwAAAHQoLAATOVQAZyFu
APotggAucIkA3Hq+ANAS2gBwavIA/0ABgAEAQwkAAEMJAADw75AAkgGSAUMJAAAAAAAAQwkAAAAA
AAACEAAAAAAAAADyCQAAQAAAEABAAAD//wMAAAAHAFUAbgBrAG4AbwB3AG4ABgBBAHUAdABoAG8A
cgAMAFIAdQBzAHMAIABIAG8AdQBzAGwAZQB5AP//AwAIAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAA
AAAAAAACAP//AwAAAAAAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAUAAABHFpABAAACAgYD
BQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBh
AG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwA
AAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAPzWQ
AQAAAgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUA
dwAAADUmkAEAAAILBgQDBQQEAgSHegBhAAAAgAgAAAAAAAAA/wEBAAAAAABUAGEAaABvAG0AYQAA
ACIABABxiIwYAPAYBQAAqQEAAAAACiOGpt1ThoYAAAAAAgANAAAAfAEAAHYIAAABAAUAAAAEAAMQ
EgAAAHwBAAB2CAAAAQAFAAAAEgAAAAAAAADBAwDwEAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABuBKUGtAC0AIGBMjQAABAAGQBkAAAAGQAAAO0JAADtCQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAEzgxEA8BAA
CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS1AAAAAAKfD/DwEAAT8AAOQEAAAvBgAA////
f////3////9/////f////3////9/+i2CAP//EgAAAAAAAAA7AFQAaABlACAAUwAvAE0ASQBNAEUA
IABXAG8AcgBrAGkAbgBnACAARwByAG8AdQBwACAAaABhAHMAIABjAG8AbQBwAGwAZQB0AGUAZAAg
AGEAIABzAGUAcgBpAGUAcwAgAG8AZgAgAFAAcgBvAHAAbwBzAGUAZAAAAAAAAAAAAAwAUgB1AHMA
cwAgAEgAbwB1AHMAbABlAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAA
AAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAKQBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAADcAAAA
BAAAAOgAAAAFAAAA9AAAAAYAAAAAAQAABwAAAAwBAAAIAAAAIAEAAAkAAAA4AQAAEgAAAEQBAAAK
AAAAYAEAAAwAAABsAQAADQAAAHgBAAAOAAAAhAEAAA8AAACMAQAAEAAAAJQBAAATAAAAnAEAAAIA
AADkBAAAHgAAADwAAABUaGUgUy9NSU1FIFdvcmtpbmcgR3JvdXAgaGFzIGNvbXBsZXRlZCBhIHNl
cmllcyBvZiBQcm9wb3NlZAAeAAAAAQAAAABoZSAeAAAAAQAAAABoZSAeAAAAAQAAAABoZSAeAAAA
AQAAAABoZSAeAAAACwAAAE5vcm1hbC5kb3QAVx4AAAANAAAAUnVzcyBIb3VzbGV5AHJraR4AAAAC
AAAAMgBzcx4AAAAUAAAATWljcm9zb2Z0IFdvcmQgMTAuMABAAAAAAI7q0AEAAABAAAAAAHzgYk5K
xAFAAAAAAGYmLiFPxAEDAAAAAQAAAAMAAAB8AQAAAwAAAHYIAAADAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN
1ZwuGxCTlwgAKyz5rjAAAAA4AQAADQAAAAEAAABwAAAADgAAAHgAAAAPAAAAhAAAAAUAAACQAAAA
BgAAAJgAAAARAAAAoAAAABcAAACoAAAACwAAALAAAAAQAAAAuAAAABMAAADAAAAAFgAAAMgAAAAN
AAAA0AAAAAwAAAAYAQAAAgAAAOQEAAAeAAAAAQAAAAAALwAeAAAAAQAAAAAALwADAAAAEgAAAAMA
AAAFAAAAAwAAAO0JAAADAAAAexAKAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAA
AAEAAAA8AAAAVGhlIFMvTUlNRSBXb3JraW5nIEdyb3VwIGhhcyBjb21wbGV0ZWQgYSBzZXJpZXMg
b2YgUHJvcG9zZWQADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAA
AAsAAAAMAAAADQAAAP7///8PAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA/v///xcAAAAYAAAA
GQAAABoAAAAbAAAAHAAAAB0AAAD+////HwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAAP7////9
////KAAAAP7////+/////v//////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYA
AAAAAAAAAAAAAAAQExw6IU/EASoAAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIB/////wUAAAD/////AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAAQAAAAAAAAVwBvAHIAZABEAG8A
YwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEB
AAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhoAAAAA
AAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAABYAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwBy
AG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAHgAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//
/////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAQAAAP7/////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBX
b3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAFIAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAA
AAAAAAAAAEBJ38d/UsQBMAAAAEACAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgH/////BQAAAP////8AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAAABAAAAAAAABXAG8AcgBkAEQAbwBjAHUA
bQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQEAAAD/
/////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuGgAAAAAAAAUA
UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
FgAAAAAQAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAM
AAAADQAAAP7///8PAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA/v///xcAAAAYAAAAGQAAABoA
AAAbAAAAHAAAAB0AAAD+////////////////////////////////////////////////////////
/////////////////y8AAAD9/////v////7////+////LgAAAP//////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////8BAAAA/v///wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAP7/////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////wMAAAAAAAAAIAAAAAEAAAAkAAAAAAAAgCwAAAAAAAAAAgAAALAEAAATAAAAHQQA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA
aQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAACAAAAsAEAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////
////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERv
Y3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4b
EJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a58AQAAOAEAAA0AAAABAAAAcAAAAA4AAAB4AAAA
DwAAAIQAAAAFAAAAkAAAAAYAAACYAAAAEQAAAKAAAAAXAAAAqAAAAAsAAACwAAAAEAAAALgAAAAT
AAAAwAAAABYAAADIAAAADQAAANAAAAAMAAAAGAEAAAIAAADkBAAAHgAAAAEAAAAAAC8AHgAAAAEA
AAAAAC8AAwAAABIAAAADAAAABQAAAAMAAADtCQAAAwAAAHsQCgALAAAAAAAAAAsAAAAAAAAACwAA
AAAAAAALAAAAAAAAAB4QAAABAAAAPAAAAFRoZSBTL01JTUUgV29ya2luZyBHcm91cCBoYXMgY29t
cGxldGVkIGEgc2VyaWVzIG9mIFByb3Bvc2VkAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAA
AAAANAAAAA==

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ELecuf028290; Mon, 14 Jun 2004 14:40:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ELec4T028289; Mon, 14 Jun 2004 14:40:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ELebhs028282 for <[e-mail]>; Mon, 14 Jun 2004 14:40:37 -0700 (PDT) (envelope-from [e-mail])
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1BZxcU-0006MZ-Si; Mon, 14 Jun 2004 15:59:50 -0400
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, smime mailing list <[e-mail]>, smime chair <[e-mail]>, smime chair <[e-mail]>
Subject: Protocol Action: 'S/MIME Version 3.1 Certificate Handling' to  Proposed Standard 
Message-Id: <[e-mail]>
Date: Mon, 14 Jun 2004 15:59:50 -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>

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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i59DGZYX064492; Wed, 9 Jun 2004 06:16:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i59DGZh9064491; Wed, 9 Jun 2004 06:16:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i59DGYUR064472 for <[e-mail]>; Wed, 9 Jun 2004 06:16:34 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id BDC4F34094; Thu, 10 Jun 2004 01:11:27 +1200 (NZST)
Received: from pgut001 by medusa01 with local (Exim 4.32) id 1BY2wW-0008Hx-An; Thu, 10 Jun 2004 01:16:36 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Anti-spam news article
In-Reply-To: <[e-mail]>
Message-Id: <E1BY2wW-0008Hx-An@medusa01>
Date: Thu, 10 Jun 2004 01:16:36 +1200
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>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i59CSA4Z058020; Wed, 9 Jun 2004 05:28:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i59CSAGw058019; Wed, 9 Jun 2004 05:28:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i59CS9JV058012 for <[e-mail]>; Wed, 9 Jun 2004 05:28:09 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 19693 invoked by uid 0); 9 Jun 2004 12:16:16 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.39.11) by woodstock.binhost.com with SMTP; 9 Jun 2004 12:16:16 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6
Date: Wed, 09 Jun 2004 08:28:07 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Anti-spam news article
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>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54KJedq076131; Fri, 4 Jun 2004 13:19:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54KJeCS076130; Fri, 4 Jun 2004 13:19:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54KJdiR076121 for <[e-mail]>; Fri, 4 Jun 2004 13:19:40 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07420; Fri, 4 Jun 2004 16:19:42 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc2632bis-07.txt
Date: Fri, 04 Jun 2004 16:19:42 -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		: 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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

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

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

--OtherAccess--

--NextPart--