At 8:27 AM -0700 2006-04-06, Harakiri wrote:
I doubt that signing a message puts more load on a
server than all the
spam filtering and virus scanning in use today.
This is actually true, signing a message (average
size) has not much impact of the server - maximum i've
seen is for PGP 200% the normal processing and 150%
more for openssl (yes, gnupg seems to be slower here
=/) - figures based on 50000 mails in a few minutes
This is doing a PGP cryptographic signature on each and every
message as it passes through the system, as compared to no
cryptographic signatures at all? I'd like to see more details of
your testing, please.
> Doing client-side signing and verification is
definitely
> scalable, but is difficult to get jump-started.
This is actually not right - because client side you
will always have the trouble to get all up to dates
CRLS, CAs, OCSP signer certs etc (im talking smime
here) and revoked keys for PGP. Do you want to update
every client every second to make sure the validation
is correct or just have *one* trusted server handle
the result which will take care of all CRLs, all CAs,
all OCSP Connections ?
I think the problem of keeping updated CRLs, CAs, etc... is going
to have to happen anyway, and I think that can be done in a scalable
manner. Teaching the clients to be able to use that system will take
some time, but should not be excessively difficult.
I dont quiet get that point here, there is actually
enterprise gateways which use DNS lookups for
ceritifcate retrievale (x509) for over 4-5
years...nothing difficult when you only use 1 key
(domain/group key) for the domain
Looking up a single DNS entry is not going to be particularly difficult.
Doing a single signing key for the entire domain is probably not
going to put an excessive load on the DNS server which provides that
information, although it will greatly increase the amount of traffic
that server handles -- instead of just handing out NS, MX and A
records which aren't likely to fill an entire 512-byte UDP packet,
now you have to add a whole bunch of crypto key data which is likely
to greatly expand the amount of information you have to provide as a
part of each transaction.
The problem comes when you have a key per user. Now you're
talking about orders of magnitude more information that has to be
handled, even with small numbers of users. And exponential explosion
in memory requirements, on both the authoritative and caching
servers, which is guaranteed to cause a major meltdown when you start
talking about tens of millions or hundreds of millions of users with
keys published via the DNS.
- even then the DNS
entries can be expended for more users and there
should be no issue at all
I think you need to look at the scalability factors before you
make such proclamations.
--
Brad Knowles, <brad(_at_)stop(_dot_)mail-abuse(_dot_)org>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
LOPSA member since December 2005. See <http://www.lopsa.org/>.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com