Outlook and just about every email client under the sun supports S/MIME. You can get an email certificate from Verisign or one of there competitiors for about $20 bucks for a year. ( there are a lot of CAs these days so choose the best price). The catch is both you and your recipient need certs to encrypt email, however only you need a cert to sign email and have it verified (your recipients email client will verify it for them).
Alternatively there is PGP, which is less common and usually requires plug-ins. Thunderbird Enigmail is the most common one for windows if I'm not mistaken. PGP is free but has no third party verification so you need an out of channel way to do a key swap with your recipient who also needs his own PGP key.
I disagree. HTTPS:// with a self-signed cert would give a false sense of security to an unknowledgeable user, which is more scary than a no security implied HTTP:// connection.
Correct, the ASF owns the trademark on Apache HTTP Server. Just like you could technically fork Java as well, but you can't call it Java unless it passes all of Suns standards.
There is also a hell of a lot more to Apache than just the HTTP server btw.
Personal responsibility has to come in at some point. People keep saying they are tired of a nanny-state and yet won't even take the time to read what they are agreeing to, then scream lawsuit in hopes that maybe that will bail them out of their stupidity.
So untrue. This is the exact relationship between CentOS and RHEL. (CentOS is built using the RHEL source, minus trademarks) and yet Red Hat still makes money selling RHEL.
This is simply Microsoft passing on the cost of the EU law suits to the consumer. EU should sue MS less imo.
Humor aside, I would be interested to see what the operating costs for delivering software products are in Europe given all the regulations/taxes and various governments that try to take a pound of flesh from you.
Ubuntu versioning is timetable based not feature based. Hardy Heron 8.04 is 2008 April. So the even/odd rule doesn't apply.
Seems like more people are moving over to time based releases these days (including the linux kernel itself), I rather like it myself.
It was an honest question, thats why I made the DNS/IP comparison, not a perfect analogy, but analogies rarely are. Seems like OpenID could make use of the already existing PKI infrastructure. What I really wanted to know is if there was a reason why OpenID couldn't be combined with PKI.
How is this any different from PKI where you have a CA vouching for you? Seems like this is just PKI "friendly version" kind of like DNS covers up underlying IPs to make it more user friendly.
Did you even read the GP? No, sorry, I forgot, to busy saying something inflammatory about the government to read things!
No, seriously, the GP said "his lawyer" not "the government" or "the judge".
Yet the Coast Guard has jurisdiction over all waters in the United States. Which happens because the feds can regulate interstate commerce, why, because rivers are a shared resource, just like airwaves.
FCC disappears it will be a contest to see who has the bigger transmitters, others be damned, and there isn't anything you can do about it. (Though I'm sure the big telco's and TV stations will work out agreements (basically a MAD scenario, but sorry if your not a huge cooperate entity you get nothing.) Would you really want to leave those decisions to the GREED of corporate America even more so than they are now?
Actually it was quite on point. FCC imo falls very squarely under regulation of interstate commerce. Radio waves are an interstate resource that can and is used for commerce.
Very constitutional.
Yes and no letting people from Rhode Island dominate a common interstate resource simply because RI would refuse to enforce restrictions on what bands could be used by radios, thus ruining that resource for states around it. All hypothetical of course, but plausible in the vacuum of non-regulation.
No, GP had it right. PKI works for the most part.
The guy who shows up in the truck (to borrow from the analogy) will have his cert, which is signed by the bank, which is signed by a CA, which is signed by a root CA. All of the people in that chain assume liability. The root CA will be someone trusted by the people who wrote the software you use, and since you installed it on your computer I assume you trust those developers, (if not you can modify your trust authorities list to fit your desires).
On the flip side, if you accept a self-signed cert the first time, and it does turn out to be bogus, the only person liable for that is you the user. Thats why browsers warn against it. Self-signed certs ONLY acceptable for encrypting traffic to an entity that you have first hand knowledge you can trust. i.e. SSLing admin functions of a website I control and run with a self signed cert, or using https to get in to my uTorrent client from work.
Yes, because Fred Bloggs cert will be signed by a root signing authority (or a CA who's cert is signed by a root signing authority) who will have been trusted enough by reputation to be put in Firefox (my web broswer) by its developers. I DO find it reasonable to trust Firefox development team to only use trusted sources for there CA list
See how certificate chaining works?
At some point you have to trust someone, but with that trust comes liability as well on the part of the trusted party. Verisign et al assume liability every time they sign another lower level CA's cert or end user cert. Not just civil liability but reputation liability. Write enough bad checks and developers will stop putting you in their software as a signing authority.
I would mod you up, but you are already at max.
This is true on so many levels. Governments have been spying on us for years, and laws or lack thereof are not going to stop that. There is no reason to think that any actions you perform on the internet will be private unless you make them so. The internet is a very public place.
Until there are laws preventing us from protecting our privacy, there isn't much of a problem. The burden is on you the USER to protect yourself, you shouldn't be trusting other "not to look".
Unfortunately you need some kind of certifying authority to verify keys in a key-exchange between third-parties who know nothing about each other. As you said you can always generate your own SSL cert and sign it yourself, but it will be an untrusted signature, and rightfully so.
I disagree, email clients have native support for S/MIME and signed PKI certificates. Conversely, most clients do not have native support for PGP, though you can get it through plug-ins (Thunderbird).
Certainly you can get a email signing cert from Verisign by paying for it (It's very inexpensive and integrates well with most email clients). You can also generate your own key pair and get it signed by Thawte (so long as you complete there "Web of Trust" requirements), if you are worried Verisign might keep a copy of your private key (they don't).
The problem with the whole system is that while only you need a PKI cert to sign an email (recipients client will auto verify it), but in order to encrypt an email your recipient must have a PKI cert and you must have there public key. That means both parties must care enough to encrypt email. This is where the envelope analogy breaks down, because to receive a sealed envelope in the mail I don't have to do anything.
Slashdot Mirror
Outlook and just about every email client under the sun supports S/MIME. You can get an email certificate from Verisign or one of there competitiors for about $20 bucks for a year. ( there are a lot of CAs these days so choose the best price). The catch is both you and your recipient need certs to encrypt email, however only you need a cert to sign email and have it verified (your recipients email client will verify it for them). Alternatively there is PGP, which is less common and usually requires plug-ins. Thunderbird Enigmail is the most common one for windows if I'm not mistaken. PGP is free but has no third party verification so you need an out of channel way to do a key swap with your recipient who also needs his own PGP key.
I disagree. HTTPS:// with a self-signed cert would give a false sense of security to an unknowledgeable user, which is more scary than a no security implied HTTP:// connection.
Correct, the ASF owns the trademark on Apache HTTP Server. Just like you could technically fork Java as well, but you can't call it Java unless it passes all of Suns standards. There is also a hell of a lot more to Apache than just the HTTP server btw.
Yes because that wouldn't promptly get you arrested at the border.
Personal responsibility has to come in at some point. People keep saying they are tired of a nanny-state and yet won't even take the time to read what they are agreeing to, then scream lawsuit in hopes that maybe that will bail them out of their stupidity.
So untrue. This is the exact relationship between CentOS and RHEL. (CentOS is built using the RHEL source, minus trademarks) and yet Red Hat still makes money selling RHEL.
How is that odd, Red Hat does the same thing with RHEL and it works out pretty well for them.
...and just because you say something in a contract isn't valid doesn't make it so.
This is simply Microsoft passing on the cost of the EU law suits to the consumer. EU should sue MS less imo. Humor aside, I would be interested to see what the operating costs for delivering software products are in Europe given all the regulations/taxes and various governments that try to take a pound of flesh from you.
Ubuntu versioning is timetable based not feature based. Hardy Heron 8.04 is 2008 April. So the even/odd rule doesn't apply. Seems like more people are moving over to time based releases these days (including the linux kernel itself), I rather like it myself.
It was an honest question, thats why I made the DNS/IP comparison, not a perfect analogy, but analogies rarely are. Seems like OpenID could make use of the already existing PKI infrastructure. What I really wanted to know is if there was a reason why OpenID couldn't be combined with PKI.
How is this any different from PKI where you have a CA vouching for you? Seems like this is just PKI "friendly version" kind of like DNS covers up underlying IPs to make it more user friendly.
Did you even read the GP? No, sorry, I forgot, to busy saying something inflammatory about the government to read things! No, seriously, the GP said "his lawyer" not "the government" or "the judge".
Except numbers in this case still tell you nothing, as the releases are not feature or bug fix based. The date system makes sense.
Music != Software. One is data, one is an application?
Yet the Coast Guard has jurisdiction over all waters in the United States. Which happens because the feds can regulate interstate commerce, why, because rivers are a shared resource, just like airwaves. FCC disappears it will be a contest to see who has the bigger transmitters, others be damned, and there isn't anything you can do about it. (Though I'm sure the big telco's and TV stations will work out agreements (basically a MAD scenario, but sorry if your not a huge cooperate entity you get nothing.) Would you really want to leave those decisions to the GREED of corporate America even more so than they are now?
Actually it was quite on point. FCC imo falls very squarely under regulation of interstate commerce. Radio waves are an interstate resource that can and is used for commerce. Very constitutional.
Yes and no letting people from Rhode Island dominate a common interstate resource simply because RI would refuse to enforce restrictions on what bands could be used by radios, thus ruining that resource for states around it. All hypothetical of course, but plausible in the vacuum of non-regulation.
However unregulated transmissions with ranges under 20-30 miles could interfere with interstate commerce if you could use any band you liked.
No, GP had it right. PKI works for the most part. The guy who shows up in the truck (to borrow from the analogy) will have his cert, which is signed by the bank, which is signed by a CA, which is signed by a root CA. All of the people in that chain assume liability. The root CA will be someone trusted by the people who wrote the software you use, and since you installed it on your computer I assume you trust those developers, (if not you can modify your trust authorities list to fit your desires).
On the flip side, if you accept a self-signed cert the first time, and it does turn out to be bogus, the only person liable for that is you the user. Thats why browsers warn against it. Self-signed certs ONLY acceptable for encrypting traffic to an entity that you have first hand knowledge you can trust. i.e. SSLing admin functions of a website I control and run with a self signed cert, or using https to get in to my uTorrent client from work.
Yes, because Fred Bloggs cert will be signed by a root signing authority (or a CA who's cert is signed by a root signing authority) who will have been trusted enough by reputation to be put in Firefox (my web broswer) by its developers. I DO find it reasonable to trust Firefox development team to only use trusted sources for there CA list
See how certificate chaining works?
At some point you have to trust someone, but with that trust comes liability as well on the part of the trusted party. Verisign et al assume liability every time they sign another lower level CA's cert or end user cert. Not just civil liability but reputation liability. Write enough bad checks and developers will stop putting you in their software as a signing authority.
You can apply that same argument to cigarettes and alcohol, and if you want to get hyperbolic about it, drugs.
I would mod you up, but you are already at max. This is true on so many levels. Governments have been spying on us for years, and laws or lack thereof are not going to stop that. There is no reason to think that any actions you perform on the internet will be private unless you make them so. The internet is a very public place. Until there are laws preventing us from protecting our privacy, there isn't much of a problem. The burden is on you the USER to protect yourself, you shouldn't be trusting other "not to look".
Unfortunately you need some kind of certifying authority to verify keys in a key-exchange between third-parties who know nothing about each other. As you said you can always generate your own SSL cert and sign it yourself, but it will be an untrusted signature, and rightfully so.
I disagree, email clients have native support for S/MIME and signed PKI certificates. Conversely, most clients do not have native support for PGP, though you can get it through plug-ins (Thunderbird).
Certainly you can get a email signing cert from Verisign by paying for it (It's very inexpensive and integrates well with most email clients). You can also generate your own key pair and get it signed by Thawte (so long as you complete there "Web of Trust" requirements), if you are worried Verisign might keep a copy of your private key (they don't).
The problem with the whole system is that while only you need a PKI cert to sign an email (recipients client will auto verify it), but in order to encrypt an email your recipient must have a PKI cert and you must have there public key. That means both parties must care enough to encrypt email. This is where the envelope analogy breaks down, because to receive a sealed envelope in the mail I don't have to do anything.