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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Trevor
Freeman
Sent: Friday, 25 June 2004 5:42 a.m.
To: Ben Littauer; ietf-smime(_at_)imc(_dot_)org
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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
* On Behalf Of Ben Littauer
* Sent: Wednesday, June 23, 2004 6:34 AM
* To: ietf-smime(_at_)imc(_dot_)org
* 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" <trevorf(_at_)exchange(_dot_)microsoft(_dot_)com>
* > Date: Tue, 22 Jun 2004 11:15:39 -0700
* > To: "Craig McGregor"
<Craig(_dot_)McGregor(_at_)treasury(_dot_)govt(_dot_)nz>,
"Russ Housley"
* > <housley(_at_)vigilsec(_dot_)com>, <ietf-smime(_at_)imc(_dot_)org>
* > 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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
* > [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
* > * On Behalf Of Craig McGregor
* > * Sent: Monday, June 21, 2004 8:12 PM
* > * To: Russ Housley; ietf-smime(_at_)imc(_dot_)org
* > * 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.
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* > *
* >