Slashdot Mirror

Become a member of CaCert.org http://www.cacert.org/.

Support their certificates and their root CA.

Advocate for support in OSS browsers like Firefox.

Tell everyone you know about CACert.

Certs want to be free like information (and beer, too).

As a CAcert member, I would love for them to be included as a root certificate in all the major browsers, including Firefox. But I understand and agree with the reasons it hasn't happened yet. It's a step above self-signed certificates, but their system does have drawbacks that you should research and understand. I do not consider CAcert sufficient for monetary transactions at this time. They have not yet documented their compliance to accepted security policies and standards. They are working on it, though.

CAcert is not GPL, they were reluctant to release their source code, and it is reasonable and prudent to require more than to just be a free CA to get your root certificate included in a major web browser.

Also, you are blaming the wrong party at this point. From CAcert's own WiKi ( http://wiki.cacert.org/wiki/InclusionStatus#head-8 5c7c27aa2c5f493507295453295a15e0132dbc9):

"Mozilla has established a fair and firm policy which CAcert should be able to meet. Then they threw the ball back to CAcert."

Don't get me wrong. I _like_ CAcert. I _use_ CAcert. I just don't think my grandmother should implicitly trust them, yet.

The big hurdle seems to be that the Mozilla Foundation won't include the CAcert root certificate in the browser because CAcert doesn't pay them (unlike all the other root authorities).

https://bugzilla.mozilla.org/show_bug.cgi?id=21524 3#c164

Pasting for those to lazy to follow the link.

Rich Freeman wrote:
>
> It just seems like as an organization we [The Mozilla Foundation]
> should be trying to foster open source projects.

Whoa, there. I'd just like to point out that CaCert is not an open source
project in any sense of the term. It uses open source software *internally* to
provide a free (as in beer) service, but CaCert distributes no free (as in
*freedom*) software, and no software that could even remotely be considered
open source. Just the opposite in fact, see the license here, on their site:
http://www.cacert.org/src-lic.php

It clearly states that you:
1. may NOT modify the source code [...]
2. may NOT make copies of the source code [...]
3. may NOT give, sell, loan, distribute, or transfer the source code files
to anyone else, an, my favorite:
4. may NOT use [CaCert] software created for any purpose or reason other than
verifying that there are no unknown vulnerabilities or the like or otherwise
making your own assessment of the integrity of the source code and the security
features of the CaCert software

Furthermore, below it goes on: "All rights not expressly granted to you
[editorial comment: which would be "none"] in these license terms are reserved
by CAcert. CaCert retains ownership of all copyrights and other intellectual
property rights throughout the world in the CAcert source code and software.
You agree that CAcert will be given a perpetual non-exclusive rights to any and
all derived code, and you hereby assign rights in any modifications you make to
the source code and in any bug reports you submit to CAcert."

This just may be the single most disgusting and ill-advised hybrid software
license I have ever read. The author apparently seeks to keep the software
100% proprietary, guarding it from "competitors", and protecting potential
future licensing revenue, while simultaneously benefiting from the efforts the
open source developer community to fix its bugs, and attest that it is not
malware, for free.

Although I wrote an impassioned comment (#12 above, of 161 so far!)
https://bugzilla.mozilla.org/show_bug.cgi?id=21524 3#c12 in *support* of
CaCaert, uh, 4 years ago now, and was a CaCert user and Assurer, I discontinued
my involvement because the source code was released by the founder only months
later, after much prompting and delay, and when it was finally unveiled, these
onerous licensing restrictions were "slipped in" with zero community
discussion.

When I asked why the code was not made open source, the founder described his
perceived threat that if it was made open source, then other free CA's would
start popping up out of nowhere to run our code and to compete with CaCert and
he felt that this would decrease CaCert's chances of getting its root cert into
Mozilla, and then IE.

This seemed a paranoid and protectionist attitude and I've no longer
participated in the Assurer program or the CaCert community since, though I
have monitored the mailing lists. After the founder's recently announced
resignation, perhaps the new board of directors (or whatever governing body
structure they adopt) will revisit this anti-competitive, closed source
position.

I had though a free CA would be a good thing, and if one is good, then two is
better, and hundred would be fantastic! So if they all *do* pop up, and share
code and development effort, I believe that all will benefit and perhaps,
someday, all will be accepted by all the browsers, and Verisign and the sma

I don't really understand what the original poster meant by saying CACert is not open source.

Well this is the license, and it seems to not allow us to modify and redistribute the source.

Here's a link to the paperwork, and here's some info about it

Here's a link to the paperwork, and here's some info about it

CAcert also offers free, personal certificates based exclusively on WoT checking, and Class3 certificates for code-signing, it's similar to Thawte's model except for the free Class3 certificates.

The big hurdle seems to be that the Mozilla Foundation won't include the CAcert root certificate in the browser because CAcert doesn't pay them (unlike all the other root authorities).

Having an open source CA is one thing. Having the root certificate included in major browsers is an expensive endeavor. The www.cacert.org site has an FAQ entry about this:

http://wiki.cacert.org/wiki/InclusionStatus

Summary: Lots of open source browsers already have the cert; Mozilla/Firefox will have it soon. Internet Explorer (and apparently Apple's Safari) won't have it unless they come up with a way to pay for the $75,000+ plus $10,000 a year for a AICPA WebTrust audit.

If you create a certificate with the x509_v3 extension subjectAltName set to a number of hostnames all those hosts can use the same certificate. I use this setup at work on an internal server that provides several name-based virtual hosts. The setup is further described here (called CN+subjectAltName). I don't know if this method is the one you referred to below:

Not only that, but free Certificate Authorities (like CAcert.org) are not allowed to issue these EV certs. Only the large commercial CAs like Verisign can issue them. reference: http://blog.cacert.org/2006/11/194.html

Not only that, but free Certificate Authorities (like CAcert.org) are not allowed to issue these EV certs. Only the large commercial CAs like Verisign can issue them. reference: http://blog.cacert.org/2006/11/194.html

The thing is, no one is going to care whether an address comes up green or white. If they ever start caring, no one is going to buy the cheap certificates anyway. This is just a mandated price increase by Verisign, or a moot point. Why not just stick CAcert's root certificate in Firefox and be done with it?

Check out http://www.cacert.org/. You can join for free, create your own certificates, and it tells you how to add cacert.org to your CA cert authority.

Apache added support for RFC 2817 to mod_ssl about a year ago, in Apache HTTPD 2.2. Admittedly, not many people are using 2.2 yet; a lot of servers are still running 1.3.

I could not find any indication that Mozilla/Firefox support RFC 2817. (I read one email archive that said it did, but bugzilla says it has not been implemented.)

I found the answer to my question regarding IE7 support: it will not support RFC 2817. It will however, support RFC 3546 (SNI) in the Vista version, which is apparently a better method of getting the same functionality. (The reply to the above Slashdot comment includes some info and links on SNI.) Mozilla does not yet support SNI. Apache does not support SNI out of the box; the mod_gnutls module does, but it's not included with Apache, and is not yet production quality. There is a patch for Apache mod_ssl.

Summary: It appears that SNI will be the way forward, but consensus and implementations still need to catch up. IE7/Vista is the second browser implementation after Opera. Apache and Mozilla do not yet support it, but are working on it. Here's a decent write-up about the situation.

email address and password do not work, unless you want everyone to know (and, why not, use) your password.

email address and a digital certificate are fine, thought. The critical point becomes the CA, but there are good solutions to that.

Bollocks.

The problem with email at the moment is that forging From: fields is trivial, anyone who knows the first thing about SMTP can do it in 5 seconds and this means that an email can appear to come from any source the actual sender wants. I can send an email to anyone and make it appear as if it's from any bank in the world.

With a signed email, if the sender(bank) email address in the From: field doesn't match the certificate then you know it's not from the real sender(bank). It's perfectly possible and indeed simple for the client to automatically check that a signed email is from who it says it's from. That's the whole point of digital signatures. It could then display a nice happy face for valid emails and an unhappy one for invalid or neutral for unsigned ones.

And certificates should be easy to obtain. Everyone should have one. Go get one now, they're free! It isn't whether you have a certificate or not that matters it's that you are who you say you are that matters and that's what certificate authorities do for you. It's then up to users check that the From address shows user@barclays.co.uk rather than user@barlcays.co.uk but at least they'll now be able to check.

You can get free certificates which can be installed in your s/mime compliant email client.

http://www.thawte.com/secure-email/personal-email- certificates/
http://www.cacert.org/
http://www.instantssl.com/ssl-certificate-products /free-email-certificate.html

More info here.
http://en.wikipedia.org/wiki/S/MIME

But you do know who you can trust. Phishing is exactly the type of thing digital signatures were designed to prevent. You know the mail doesn't come from the bank/whatever because it isn't signed by them, the From address is a fake, the key retrieved from the PKI servers for that address will not match the signature. That's the whole point of digital signatures. They guarantee that X sent an email and that it hasn't been tampered with in transit.

Postbank in Germany btw, is the first bank to introduce digital signatures.

As to who produces the infrastructure. Well, anyone who would like reliable trustworthy email system should be involved, that means getting and using a certificate. It's free:

http://www.cacert.org/

First, I'll agree that, yes, CAcert is not supported by anything I know of. Mozilla finally got its act together and published a policy. The ball's in CAcert's court, last I heard; they need to have an audit done.

As I understand it, the point of the system is not to act as a content filter, but simply to establish identity. For e-mail certificates with no name (just the address), they simply send an e-mail probe. For domains, they run a WHOIS and you select one of the e-mail addresses in the registration info. If you actually want a name on your certificates, you must be assured by two people, who can be someone already in the web of trust or one of several widely trusted third parties. These procedures are comparable to the ones used by CAs that are installed in browsers, at least for their lower levels.

I really don't understand the belief that "only people with $20-1500/yr need to be authenticated." Really, anytime you send secret/valuable data, it should be sent to an authenticated server over an encrypted channel. CAcert is a program that provides some hope of achieving this. The other big thing is Server Name Indication support and the retirement of SSL2; that will allow multiple SSL certs per IP, removing another costly barrier.

Let's be realistic here: how many people actually use a different password for each website that uses one? how many of these sites actually use SSL?

If your gripe is based on some problem with CAcert's execution, then I encourage you to ignore this rant and elaborate on your points.

cacert.org

See http://www.cacert.org/ for a solution to getting CA's at the price they SHOULD BE ... ZERO, NADA, ZILCH. If enough people get in here, then it'll be a likely candidate for a Root level certificate in all browsers and systems.

www.cacert.org

Ah, ah ah.... Free SSL certificates are available here, and browsers trust them.
http://www.cacert.org/

Bullshit! CaCert is not trusted by any browser with any marketshare above .5%.

The only free ssl certs you can get are usually limited to 30 days.

Ah, ah ah.... Free SSL certificates are available here, and browsers trust them.

http://www.cacert.org/

You better re-examine your idea of security here. For starters, your ISP that you connect your server to can easily store both sides of a conversation...it has to pass through their server *both ways* for you to communicate.

Well, no.

If you truly run your own mail server, with MX records rather than using your ISP's POP box as a store-and-forward, then it isn't going through their server. Technically ;>. The only real difference this makes is that your communications clearly fall under the Pen Register rules rather than the Wiretap rules when the authorities try to legally obtain info about your communications.

It does still go through their network. But that's a (slightly) different matter. Yes, they can still sniff the traffic both ways. This is where StartTLS comes in. If your mail server offers StartTLS, and the remote mail server is willing to try it, then everything except the EHLO of the SMTP transaction is encrypted just as HTTPS web pages are.

You can easily set up most mail servers to run "Opportunistic" StartTLS. That is to say, "Offer it, and take advantage if someone else offers it, but don't require it." For the purposes of encryption, it doesn't matter that most people will use self-signed certificates. (Yes, that kills authentication.)

You can also require StartTLS, but that would impact your ability to send and receive mail to sites not configured to do StartTLS. (But for the paranoid, it bears mentioning.)

Google quickly found a few sites for various mail transfer agent configurations:

• Postfix
• Sendmail
• Exim
• Qmail
• Exchange (no good link, and may not allow opportunistic)

In short... my mail server secures mail with anyone else who cares to do so. If you are enough to run your own server, consider caring enough to offer and take advantage of StartTLS encryption.

N.B. - If self-signed certs are a pain (and they are), look into CAcert.

The trouble with cacert and other similar web-of-trust schemes is that
they confuse different sorts of trust. Even if ten or even a thousand
people have checked that someone claiming to be Dr Evil really is Dr
Evil, it doesn't follow that Dr Evil's claims about the identity of
another individual should be believed.

Web-of-trust schemes which do not recognise this distinction will be
vulnerable to an exploit whereby "verified-identity" can be elevated
to "presumed-reliable-authenticator".

The bottom of this page from CAcert's FAQ seems to admit that
their scheme is vulnerable to such an exploit.

One can at least mitigate the money issue. http://cacert.org/ is an alternate "open" root cert authority. They're working hard to gain the acceptance of the likes of verisign. I've had converstions with a few of them, and its arguable that their verification procedures are _more_ rigorous than those conducted by the the CA's that are charging high prices.

Nevermind the fact that if noone is buying certs, theres no finanical pressure to cause them to make any compromises for those willing to pay the right price.

I'm not paying for such a certificate either. But there are alternatives like http://www.cacert.org/
IMHO it is better than selfsigned but still vulnerable to the same schemes.

For some internal (non user-facing) things I have used a self signed cert; for example when prototyping cosign (web single sign on).

In the past we have rolled out a CA signed by CREN. This was a pretty small rollout and used for just Shibboleth, S/MIME, Web Auth, and some limited classroom work using handheld devices. At this point we are using mostly Thawte Freemail for S/MIME and CACERT for S/MIME, PDF signing, 802.1x, and a odd series of other tests/work.

This is less than ideal since we end up beholden to corporate groups, but there is something good on the horizon, USHER Usher is a higher ED CA being put together by Internet2 which will be cross certified with the Federal CA bridge. Basically what CREN was supposed to be, only with more backing and interest.

The nice thing about it is that we will get a signing cert to use at will rather than paying someone like Verisign per certificate which is not gonna happen with 138,000 users, especially if we wish to do any kind of PKI-LITE setup (where short term "junk certs" are issued on demand eliminating the need for a CRL which nobody has figured out how to do right yet).

> For example, SSL certificates aren't free, unless they're self-signed

http://www.cacert.org/

Bad example.

A genuine 'tax' aspect will be coming in the form of the patent rights in the codecs needed to encode to the media.

The kind of closed systems you are worrying about already exist in signed games for consoles and the special optical media needed for PSPs, but isn't credible to take camcorders and HD camcorders out of the public's hands. AFAICT all upcoming AV systems for TV-style use will naturally allow unencrypted content at the highest quality going on.

People are producing free media content at the moment, eg,

http://channel101.com/
http://channel102.net/

it's not such a great leap to imagine that from these small beginnings in a few years one will be able to at least get part of your entertainment needs direct from the Internet to your HD TV without DRM at all. The more restrictive the traditional media the better the chance for growth in the liberally licensed stuff, so I have come to welcome and encourage all this DRM garbage so long as unencrypted content plays by default.

The SNI (server name indication) extention is considered to be a better solution for HTTP than SSL Upgrade and hopefully will soon be supported by browsers and servers. (Opera and mod_gnutls already do).

http://wiki.cacert.org/wiki/VhostTaskForce#head-78 b8f803f17fa69b4333aa376a641b2e843c2cb3
http://www.outoforder.cc/projects/apache/mod_gnutl s/
https://bugzilla.mozilla.org/show_bug.cgi?id=11616 8

CAcert.org has had about 50% netscape/firefox usage for the best part of 1-2yrs...

You are not understanding how Smartcard based PKI works. The smart card isn't a flash drive with a serial number on it. It is a full crypto engine and a microprocessor.

When you do a transaction with a smart card, the card is sent a string to encrypt using its private key. The card then requests your PIN in order to access the private key. Once it gets your pin, it encrypts the data and sends only the encrypted data back out.

To make it simple, the following examples assume the public keys have alredy been appropriately exchanged and loaded, as would be the case when a bank issues a card to a customer.

Apply this to a bank's online portal. The site needs authorization to login, so it sends a authentication code to your computer. Your computer hands that code to your smart card, with instructions to encrypt it. The card then requests the pin number from the user. The user enters in their pin, which enables the card to encrypt the data. The smartcard then sends the encrypted data back to the computer which sends it to the bank. The bank receives the data and decrypts it, using the public key associated with your card. Since it has confirmation that you encrypted it based on the public/private key pair, it authenticates you.

The thing to remember is with smart cards, the private key and your PIN NEVER leaves the card. A person can have data encrypted by your card, as a MitM would have, and could even have your PIN, but if they don't have your physical card, they can't do anything with it.

They can replay that authentication packet they recorded all they want, but since the bank uses a different authentication code every time a login is requested, the bank will know that your card did not perform the authentication and reject it.

Do some research on Publick Key Infrastructure. Your argument would be valid if the info the smart card was sending was static. However, since all encryption is done on the card itself without ever exposing your keys, your example does not apply to this situation.

One place you can learn about PKI is at http://www.cacert.org/ which is a community driven SSL certificate authority, similar to Thawte and Verisign. You can get both client and server certificates at no charge, and there are code examples on how to set up SSL logins to your website. PKI will work without a smart card, but without a smart card someone could potentially steal your private key without you knowing it. A smart card prevents that as you will know it is gone and can have it revoked.

I hope this helps clear things up for you, please feel free to contact me if you have questions.

Jeremy

Which of course begs the need for open certification using an open trusted CA, rather than the current prevalent pay money to obtain a cert model. (Especially paying money to Verisign...brrrr.)

Check out https://cacert.org/. I'd like to see a project like this get more milage, become a root certificate installed by default in browsers, etc. Perhaps if getting a CA was actually based on trust, rather than on dollars, we'd see more signed code in the wild.

You should give a try to http://www.cacert.org/ it's not yet included in major browsers, but aims to do so, so you can get a free C.A. for your personal use... users that already included cacert root autorithy certificate will trust on you also....

Freedom: http://www.cacert.org/

CA Cert has been doing this for a while now as mentioned in this slashdot article.

https://www.cacert.org/
which makes it about as valuable/useful as the price they charge ($0)
people/biz pay the money so their customers are NOT prompted, i can sign my own certs (in about 5 lines of bash) if i dont care about the user getting dialogs

I've always used cacert.org for free SSL certificate s. :)

http://www.cacert.org/

That's all I have to say 'bout this.

How about free certificates?

Slashdot had a story a while back about a free certificate authority with identities assured by meeting personally with already assured members. It actually sounds like better assurance than what you get with Verisign.

I wish SSL would die instead of being a Certificate money making machine.

You might want to check out CAcert for free certificates.

not sure what you meant by "OSS cert project" ...

but how about http://www.cacert.org

rho

Very good indeed. I'd suggest trying OpenPGP on people (I like _distributed_ over _centralized_) and if they don't bite you can try to get them to use S/MIME. The no-extra-work factor will help in many cases indeed.

Free certs can be had at CAcert.org as well. Not only will they give you a free email cert, they'll give you a SSL cert for your web site, sign your PGP/GPG keys with their signature and they even allow you to login to the site with a certificate (no password needed to update your info or login to renew cert, etc.)

More resources?? - Reply with links please!

See my other post with links on how to setup TLS for your mail server, more info on building the web-of-trust, and GPG downloads for your windows friends.

http://yro.slashdot.org/comments.pl?sid=132181&cid =11046941

Also note that the ======== http://link ======== at the end of the parent post has been mangled by Slashdot Submissions Co. and should be fixed before forwarding it on to your friends, or posting anywhere. Broken links have never impressed anybody.

WTF - Here are some links from the link above again. Sorry about the bandwidth wastage but I think it's worth people seeing as practices contained within are sure to benefit us all (in Utopia - yay!)

[--snip-- (abridged) ]

WinPT :: Windows Privacy Tray [sf.net] is a good place to direct your friends still using windows.

I think a resource for mail administrators on how to add TLS capabilities to their SMTP handlers could be healthy for the net as well. On there would be step by steps on how to TLS-enable sendmail, postfix, qmail, proprietary-this, and proprietary-gateway-that.
:: Sendmail
:: Exim
:: Qmail

If you're running Postfix you've got little excuse to not be running TLS.
http://article.gmane.org/gmane.comp.encryption.gen eral/979

My SMTP traffic is opportunisticly TransportLayerSecure. Is yours?

Get a free server certificate from cacert.org If you haven't already you should add their Root Certificate to the list your browser accepts. They will also remotely sign your PGP/GPG keys and issue free S/MIME certificates as well. Very cool, totally free, and a distributed trust model rather than a top-down, it'll-cost-you-$199.00-for-an-SSL-cert model.

For more keysigning fun DO NOT MISS http://biglumber.com/! Find people nearby and extend your web-o-trust.

Host a keysigning party at] your next LUG [debian.org] meeting .

You can get a email-address-verified signature at http://www.imperialviolet.org/keyverify.html

Learn about using subkeys .

- - - - - - GPG keys -- The new web. - - - - - - -

[--snip-- (abridged) ]

See my other post with links on how to setup TLS for your mail server, more info on building the web-of-trust, and GPG downloads for your windows friends.

http://yro.slashdot.org/comments.pl?sid=132181&cid =11046941

Also note that the ======== http://link ======== at the end of the parent post has been mangled by Slashdot Submissions Co. and should be fixed before forwarding it on to your friends, or posting anywhere. Broken links have never impressed anybody.

WTF - Here are some links from the link above again. Sorry about the bandwidth wastage but I think it's worth people seeing as practices contained within are sure to benefit us all (in Utopia - yay!)

[--snip-- (abridged) ]

WinPT :: Windows Privacy Tray [sf.net] is a good place to direct your friends still using windows.

I think a resource for mail administrators on how to add TLS capabilities to their SMTP handlers could be healthy for the net as well. On there would be step by steps on how to TLS-enable sendmail, postfix, qmail, proprietary-this, and proprietary-gateway-that.
:: Sendmail
:: Exim
:: Qmail

If you're running Postfix you've got little excuse to not be running TLS.
http://article.gmane.org/gmane.comp.encryption.gen eral/979

My SMTP traffic is opportunisticly TransportLayerSecure. Is yours?

Get a free server certificate from cacert.org If you haven't already you should add their Root Certificate to the list your browser accepts. They will also remotely sign your PGP/GPG keys and issue free S/MIME certificates as well. Very cool, totally free, and a distributed trust model rather than a top-down, it'll-cost-you-$199.00-for-an-SSL-cert model.

For more keysigning fun DO NOT MISS http://biglumber.com/! Find people nearby and extend your web-o-trust.

Host a keysigning party at] your next LUG [debian.org] meeting .

You can get a email-address-verified signature at http://www.imperialviolet.org/keyverify.html

Learn about using subkeys .

- - - - - - GPG keys -- The new web. - - - - - - -

[--snip-- (abridged) ]

That's what Sender Policy Framework and DomainKeys are designed to stop.

The expense of verifying real-world identities is why there aren't free SSL certs out there...

Actually, CAcert gives out free SSL certificates, if you can successfully interact with their web of trust.

Now, the PGP Global directory could certainly be subject to man-in-the-middle attacks if a malicious third party can actively read and respond to at least some of your incoming e-mail. That party could upload a bogus key and respond to the confirmation-request for you, then read things sent to you. Of course you'd find out when you saw strange unreadable signed messages coming to your account...

I also don't like the essage I got from the beta keyserver after I submitted my key today:

To ensure that your PGP software trusts keys verified by this directory, you must download and trust this directory's Verification Key.

Download the Verification Key

After downloading, import the Verification Key into your PGP software. Then, sign the key with your key and mark it as Trusted. Please see the documentation for your PGP software for specific instructions on trusting a key.

The directory seems like a highter-quality way to get keys, but I don't want to trust it *that* much; on the other hand, the Key Verification Policy seems to cover the same concerns that have been expressed here.

Does anybody know of a good clearinghouse with information on plugins for a variety of mailers I could send my dad, high school friends, or grandmother to?

Anybody know of a list out there that collects information on how to secure your email, what's it's all about, and general key maintainence issues (for "the everyday net user")?

WinPT :: Windows Privacy Tray is a good place to direct your friends still using windows.

I'd like to be able to say to a friend: "Here's my key. Go to keepitprivate.com and find a plugin for the email software you use. Then next time you send me some email, just be sure to put it in an "envelope" (it just takes one extra click or can be set to happen automatically). You don't even need to lick a stamp! I value your privacy as much as I hope you value mine!"

I think a resource for mail administrators on how to add TLS capabilities to their SMTP handlers could be healthy for the net as well. On there would be step by steps on how to TLS-enable sendmail, postfix, qmail, proprietary-this, and proprietary-gateway-that. My SMTP traffic is opportunisticly TransportLayerSecure. Is yours?
Red Hat :: Sendmail
:: Exim
:: Qmail

If you're running Postfix you've got little excuse to not be running TLS.
http://article.gmane.org/gmane.comp.encryption.gen eral/979

Get a free server certificate from cacert.org If you haven't already you should add their Root Certificate to the list your browser accepts. They will also remotely sign your PGP/GPG keys and issue free S/MIME certificates as well. Very cool, totally free, and a distributed trust model rather than a top-down, it'll-cost-you-$199.00-for-an-SSL-cert model.

For more keysigning fun DO NOT MISS http://biglumber.com/! Find people nearby and extend your web-o-trust.

Host a keysigning party at your next LUG meeting.

You can get a email-address-verified signature at http://www.imperialviolet.org/keyverify.html

Learn about using subkeys.

- - - - - - GPG keys -- The new web. - - - - - - -

Does anybody know of a good clearinghouse with information on plugins for a variety of mailers I could send my dad, high school friends, or grandmother to?

Anybody know of a list out there that collects information on how to secure your email, what's it's all about, and general key maintainence issues (for "the everyday net user")?

WinPT :: Windows Privacy Tray is a good place to direct your friends still using windows.

I'd like to be able to say to a friend: "Here's my key. Go to keepitprivate.com and find a plugin for the email software you use. Then next time you send me some email, just be sure to put it in an "envelope" (it just takes one extra click or can be set to happen automatically). You don't even need to lick a stamp! I value your privacy as much as I hope you value mine!"

I think a resource for mail administrators on how to add TLS capabilities to their SMTP handlers could be healthy for the net as well. On there would be step by steps on how to TLS-enable sendmail, postfix, qmail, proprietary-this, and proprietary-gateway-that. My SMTP traffic is opportunisticly TransportLayerSecure. Is yours?
Red Hat :: Sendmail
:: Exim
:: Qmail

If you're running Postfix you've got little excuse to not be running TLS.
http://article.gmane.org/gmane.comp.encryption.gen eral/979

Get a free server certificate from cacert.org If you haven't already you should add their Root Certificate to the list your browser accepts. They will also remotely sign your PGP/GPG keys and issue free S/MIME certificates as well. Very cool, totally free, and a distributed trust model rather than a top-down, it'll-cost-you-$199.00-for-an-SSL-cert model.

For more keysigning fun DO NOT MISS http://biglumber.com/! Find people nearby and extend your web-o-trust.

Host a keysigning party at your next LUG meeting.

You can get a email-address-verified signature at http://www.imperialviolet.org/keyverify.html

Learn about using subkeys.

- - - - - - GPG keys -- The new web. - - - - - - -