New Extended SSL Certs Make Online Debut 106
An anonymous reader writes "The first of the new 'extended validation' SSL certificates
went live this week, signaling the latest effort by the browser makers and major Web sites to further verify the identity of SSL applicants and help consumers spot fraudulent Web sites, the Washington Post's Security Fix blog notes. The technology is pretty simple: Visit a login page for a site that uses one of these EV certs and the browser bar turns green; likewise, the browser's anti-phishing filters can turn the URL field red when the user is at a known phishing site. There is still quite a bit of debate over whether this whole scheme isn't just a new money-making racket for the SSL providers, and whether small mom-and-pop shops will be able to afford the pricey new certs."
It isn't whether they can afford them. (Score:5, Informative)
It's whether they'll be allowed to purchase them.
Re: (Score:3, Insightful)
Re: (Score:1)
Re: (Score:2)
The woman quoted on the WSJ site does not have a certificate today, she uses a Paypal shopping basket. So quite why she thinks that she would want an EV cert is not clear.
Mom and Pop shops that are incorporated can get a cert like anyone else. The issue is not size, it is what is being authenticated. The EV stage 1 rules specify minimum standards for authenticating incorporation creden
Re: (Score:3, Funny)
There are many problems - some are legacy problems (Score:5, Insightful)
It is far worse than that:
In the end, the benefit of SSL is that of encrypted traffic. The data goes from the client to the server, and nowhere else. That's what a certificate actually ensures. Nothing else. Not one blessed thing. The people who built this scam were either miserably uninformed and/or confused, or underhanded types who recognized the money to scooped up from people who could not afford to have a browser inaccurately claim that their business "might be a scam."
This is just one more case where superficial thinking about something is being used as an excuse to generate a large and healthy cash cow over and above the current certificate scam. Nothing can legitimately substitute for you checking for complaints, longevity, experience with the product(s) you are interested in, that sort of thing. Which in turn means that by definition, the foisting off on the consumer that the "browser bar turning green" means "shopping or interaction is OK" is outright illegitimate.
And will any of that stop this from happening? Not a chance. Because it isn't only the consumers that are failing to do due diligence here; it is the browser writers as well, and as per usual, we start with Microsoft who does not have the consumer's best interests at heart.
The attempt is being made here to do something that is impossible. Wy? Because an operation that was trustworthy yesterday can become untrustworthy tomorrow. Likewise, an operation that was controlled by scammers can replace those people. It is a matter of people and goals that no one can see through the veil of the Internet. This is aside from the creation of a "ghetto" of untrusted merchants who cannot get certified, or cannot afford to get certified.
I saw a comment elsewhere here by some moron who was pontificating about how "if some business cannot afford $500 for this cert, I would not trust them, etc. ad nauseam." The fact is, some businesses are striving on the edge and that money is important to them. Seeing as how it does nothing for them but keep them from being creamed by this new scam - meaning, it doesn't add value to what they do, just brings them back to a status quo
Re:There are many problems - some are legacy probl (Score:2)
The purpose of a certificate is for a server (or less commonly a client) to "prove" that the public key it's presenting belongs to the entity that its peer intends to communicate with. If you don't know that you're using the right key, what's the value of encrypting? I agree that many CAs have weak verification processes, and since any CA can certify
Re: (Score:2)
It can't "prove" any such thing. A simple security breach, or intended malfeasance on the part of the cert holder, and you're talking to someone else. The idea that it could prove such a thing more than half a second after it is issued is 100% illusion.
How do you trust a site? (Score:2)
I don't know about others, but having a valid key from a CA doesn't make me trust the site any more. I don't care if they have "levels" of trust. I look for a CA to verify the site is who they say they are and there is no man in the middle attack (supposedly).
I trust the site based upon what I know about the company behind it. If I don't know anything, I'll try searching for info about them before I buy.
The issues for me are:
Re:It isn't whether they can afford them. (Score:4, Insightful)
Thats because we all know there is no such thing as a shady corporation with enough money for expensive certifications.
Re: (Score:2)
I would add incompetent companies to that. Plenty of companies will lose info, send the wrong package, send to the wrong address, have really stupid policies, etc. Every company will have problems from time to time, but some more than others. You won't have any idea unless you check them out, and no cert is going to tell you what issues a given company has.
Dealing with screw-ups can be as bad or worse than a scam....
in addition, even if the cert does weed out all pure scammers, I doubt it will take out
Re:It isn't whether they can afford them. (Score:4, Insightful)
Ironically, it's much easier to establish an individual's identity (many databases that you can look in and merge, require multiple forms of ID, etc.) than the fact whether an individual is actually a proper agent of some huge megacorporation.
Re: (Score:3, Informative)
Very true, and my experience is that most places don't even make an effort.
Last year, I decided to get a signed certificate for a site that my company uses for internal purposes. When I provided the information, the CA called me and pointed out that I needed to pro
Re: (Score:1, Offtopic)
Yet another poorly moderated comment. The parent is not "Informative": neither does it quote detail nor simply related to another. It is an original thought developing insight into the consequences of the system under discussion.
It seems most slashdot moderators have insight and information confused. Compare the above to this comment [slashdot.org] which is informative, not insightful.
Re: (Score:2, Funny)
By the way, the worst job search page ever created.
Re: (Score:2)
Most mom-and-pop shops probably go through an order clearinghouse like PayPal anyway, so once you go to the order page there'll be a green bar.
-b.
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
Length of time that a company has been in business is a pretty good indication of legitimacy. The question is how to codify the rules in a form that works internationally.
There are certainly sole traders who hold organizational validation certificates today but the vast ma
Re: (Score:2)
It's a *hell* of a lot cheaper [swiftformations.com] than that.
Your lawyer was price gouging.
Re: (Score:1)
The reason why it's cheaper for shell corporations is that they're exactly that, pre-generated cookie-cutter shells. Getting an existing, operating business switched over requires considerable legal work, and is there
Re: (Score:1)
It's whether they'll be allowed to purchase them.
Re: (Score:2)
Re: (Score:2)
Not allowed? By whom? I understand if Verisign very much would want this, but do they have that power? Are all browser vendors in on this "conspiracy"?
Interesting problem (Score:3, Insightful)
I predict (brave of me, I know) that no matter what efforts are made to protect Internet users, there will still be phishing on the Internet.
I think we're better off with the training.
Six dumbest ideas... (Score:3, Insightful)
The Six Dumbest Ideas in Computer Security [ranum.com] - See #5 - 'Educating Users'.
Re:Interesting problem (Score:4, Insightful)
Re: (Score:2)
The best teacher is experience. Once the stupid and careless people get burned once or twice, I'm sure that they'll learn to be more careful in the future. Their lesson just might be a bit more expensive than the lesson given to quicker learners. BTW, in my experience, if you just look at the URL bar before entering private information, this takes care of 999 out of 1000 spam/phishing scams. If t
Re: (Score:2)
Certainly, just as soon as our fifty million trainers finish eradicating AIDS through instructing people to practice safe sex.
The small guy is getting shafted (Score:4, Insightful)
The smallest of legit web sites will not pay this, especially when they're just starting up. Add to that the requirements (what type of corporate entity the site belongs to) and you'll have few small takers. This is definitely going to hurt small sites as all of the medium and large sites will eventually sign up. Users will eventually expect the green bar on every site where they might do business. So I see this as merely a money making scheme. If they really wanted to improve security they wouldn't rely on the type of corporation or charge such high fees.
Re: (Score:2)
> business. So I see this as merely a money making scheme. If they really wanted
> to improve security they wouldn't rely on the type of corporation or charge
> such high fees.
It isn't just a money-making scheme. It also serves to drive out small businesses and set the bar higher for startups.
Re: (Score:2)
Re: (Score:2)
I'm not necessarily disagreeing with you, but it is also possible that so many legit businesses will fail to get these, that people will expect them only for the largest corporations. In other words, people will get so used to seeing a yellow bar or whatever color they choose, that they'll start ignoring it.
Another option is to use a payment processor who's big enough to afford one of these and make it clear to custome
Re: (Score:2)
I predict differently: it's eventually not going to matter at all. Since only a small percentage of online destination will make the bar turn green, it'll never be viewed as a necessity - merely as a shiny luxury item that certifies a site is big and expensive. But (IMO) it will not decrease the volume of business for small sites and it will never become standard expectation. Not at those prices for
Re: (Score:2)
Re: (Score:3, Insightful)
There are plenty of home-based businesses that have essentially zero capital when starting up. Remember that $500 is a lump-sum payment and can equal a month's rent for some people in some places. You could use a payment processor or even only accept money directly face-to-face, but will people start thinking that all companies without a
Doesn't matter. (Score:2)
Don't trust anybody - not even yourself!
Re: (Score:2, Informative)
Re: (Score:3, Informative)
It will download a data structure in which the public key and some character strings are authenticated with yet another party's private key.
The rest is hope and trust that the signer does due diligence and hasn't been compromised.
If the "certificate" does prove who you're communicating with, SSL doesn't tell you that until you click on the padlock and look up certificate properties. Until then, all it's told you is that the domain name matches.
Re: (Score:2)
The only thing that SSL actually tells you is that the traffic you have is encrypted.
Maybe I'm not understanding what you're saying, but part of the idea of SSL certificates is also to verify that the site you're connecting to is actually the site it's claiming to be. You can use SSL to encrypt the traffic without this feature, and maybe there are ways around SSL anyway, but if you don't want 3rd-party certification of your identity, you don't need to pay for SSL certs anyway.
That depends upon how you mean that. (Score:2)
That depends upon how you mean that.
If I get a certificate issued to server "apple" at "berry.com" with address 123.456.789.012, then that is all that you know from that certificate. The server's resolved name and address match the server name and address for which that certificate was issued.
But that is all you know. That mean
Nice gig for the Certificate Authorities (Score:3, Insightful)
Since they've done such a bad job of this so far (it was quite strict at first), they've now turned around and offered a more expensive certificate with the promise that this time they'll _really_ do their job.
I've no doubt they'll get away with it when all the big names buy the more expensive certificates and see an opportunity to squeeze out the smaller competition, and/or otherwise help to raise the barrier to entry for their market. Watch this get a lot of media attention and advertising.
Re: (Score:2, Interesting)
The only certs I trust are the ones I personally sign. So when I am on a PC without the signing CA, it pops up and I can view it. If it isn't mine or one I expect I know a Bluecoat or some other SSL in the middle device is at work. The only way I know to protect against it is to view the cert each
Re: (Score:1)
Well there Sales operation is good and no im not trying to troll
Looking into certs, requested a free pdf, send all your details, click ok and wham bang thank you mam expect a pdf to download - nothing there. Think about something else and a week later Vogan from verisign rings
can i help
I politelly tell him that his request form was screwed up and no we would not be using you and could he please go jump under a train.
I learnt to make my own ca's - Vogan and Versign pretty useless but good at sal
Re: (Score:2)
The certificate authorities are supposed to be involved in the b
Re: (Score:2)
They sent the cert the same day.
Verification of 'limited company' status is bullshit anyway. I can buy an off the shelf limited company for £30 over the web, and apply for a certificate tomororrow if I want.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
> stored on the receivers end, and that's probably a larger point of failure than a
> man-in-the-middle attack
You are correct. Nor does it indicate whether they have a keylogger installed on their system either. So, you have two effectively untrusted ends and a secured channel between them, yielding, at best, a modest increase in security.
Encryption should almost be the default nowadays. That is completely separat
Verifying fingerprints is even more secure (Score:3, Interesting)
Unfortunately, browsers make this unnecessarily difficult, and few sites (even online banking sites) publish their fingerprints offline. Wouldn't it be easy for a bank to print the fingerprints in a letter sent to the customer, possibly together with his credit card etc.? If then there were an easy way to show this fingerprint in a web browser, without clicking through several layers of complicated 'key details' pages, people could actually be sure to connect to the correct site.
Additionally, I miss a feature to lock a site to a given key. Say, I'm regularly connecting to the same site, like slashdot. I don't care if the slashdot site is actually related to some company with the same name, or whatever CAs try to tell me with their certificates. All I want to know is if the site I'm sending my password to is really the one I have been visiting since several years, or a fake one trying to steal my password. So all I need is a big warning whenever the site key changes.
Both are not too difficult to implement, I guess, but users need a little more training than just telling them 'a green browser bar means secure'.
Re: (Score:2)
Of course, I could miss that little difference in the domain names. But that's not solved by high-security-certificates, either, as slashdut.com may actually be registered by a corrupt company with that name and may have bought a matching high-security-certificate.
Together with my 'lock current key to current site'-idea, this could be solved by making the browser bar green only if
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
That's really trustworthy! (Score:4, Insightful)
The example in the article immediately points out a failure of this idea. Go to entrust.com and your address bar turns green. And who is the CA that has verified that this site is really operated by entrust? "Entrust or an independent local registration authority has verified that Entrust Inc is an existing business and owns or operates the domain name www.entrust.com".. Yeah. So, this is basically a self-signed certificate, but it turns up green, because you're supposed to trust entrust, because you're supposed to trust entrust, because you're supposed to trust internet explorer.
Meanwhile, their 'extra validation' CPS states that they offer no warranties or guarantees, nor any detail about what they DO do to make extra super sure they don't issue certificates to some random Joe.
Re: (Score:2)
If you did ship a normal end-user a browser that trusted nobody, it would be equivalent to shipping one that trusted everybody, as they'd learn to "just click 'yes'", so while it's theoretically superior, it isn't practically. You can try this; you're free to remove all that automated trust.
Although you could make a case that no automated trust is better than inaccurate automated trust.
I
Re: (Score:2)
Re: (Score:2)
IIRC, and in the italian localization, ie6 said about my site that the user CHOSE NOT TO TRUST that CA (I setup my own CA, it's for internal use). Except that user never did that (especially at first connection)
ie7 says "blah blah... connect to site anyway (discouraged)"
At least firefox is honest, says "I can't verify this CA, do you want to trust it always, for this session, never?"
As i said i have no public users so i can instruct people to trust the CA. Pub
Re: (Score:2)
Who honestly leaves that thing turned on at all times?
Re: (Score:2)
You're assuming that they're in the business of being secure and trustworthy, as they claim. It makes more sense if you think about their business as taking a toll on e-commerce websites.
"Pay us money, or Internet Explorer will tell your customers not to trust you"
Would it matter to them if a load of peop
Re: (Score:2)
Re: (Score:2)
And continue trusting after it's been installed for a while. Bruce Schneier once asked the obvious question of how hard it was to add a new trusted root. It's trivial, and there's a "web accelerator" on the market that installs itself as a new trusted CA so that it can proxy SSL traffic.
Comment removed (Score:5, Interesting)
Gripes with HTTPS (Score:5, Informative)
If you don't pay the Powers That Be, you can still make your site more secure, but it will appear to be less secure.
The way HTTPS normally works is that you create a key to be associated with your domain name. This key is then signed by some certificate authority (supposedly after verifying you are you). If the certificate authority is one of those trusted by your visitors' browsers, the browser will go ahead and use your site, as well as display some indication that it is secure. The security includes both encryption (confidentiality) and authentication (you're really communicating with foobar.com - VeriSign says so).
However, you have to pay the certificate authority to sign your key. If you don't, you can still sign the key, but it won't be trusted by browsers. So far so good. The problem is that browsers will scream bloody murder, because they can't verify that you are you, making at look like you're attempting some kind of scam, while, actually, you're offering your visitors encryption. It's not as secure as encryption and authentication, but it's still better than plain HTTP - a protocol which browsers will accept without a hitch.
As a minor issue, the SSL key is sent during the connection set up, before the client can send a Host: header. This means that each host wishing to employ HTTPS has to have its own IP address - otherwise, the server doesn't know which key to use. There's actually a way around this: HTTP 1.1 specifies how to upgrade a connection to HTTPS, which can be done after the Host: header has been sent. Unfortunately, a lot of software appears not to support this feature.
Re: (Score:2)
I think what you have identified is a bad UI, not really a HTTPS problem. A browser shouldn't create popups or other warnings when
Re: (Score:2)
Re: (Score:2)
In order for an unauthenticated connection to actually be secure, you have to trust *every* *single* router your packets cross, because *any* of them can trivially break your encryption. Do you trust your ISP? Your ISP's ISP? Every other ISP between you and Amazon? Do you trust the coffee shop wireless access point? The f [slashdot.org]
Re: (Score:2)
I disagree. It does prevent people from eavesdropping on your communication, which is valuable in itself. Sometimes, it's even enough: for example, for anonymous services, or for setting up a secure channel for authentication.
It's also worth pointing out that the authentication that SSL (and HTTPS) uses by no means guarantees that the other party is who they say they are. Yes, they have a key which was signed by a party which your so
Re: (Score:2)
You're obviously ignorant of many important aspects of how a practical PKI works. Two of the key things that a CA does are to publish a list of certificates that have been withdrawn before their scheduled expiry, and to add a URL to each cer
Intranet based applications anyone? (Score:2)
The UI for our product is web-based, and of course we prefer it be SSL encrypted, as it can contain sensitive information. But because the product is always deployed AFTER sale by our customers on some private IP address, with god-knows-what hostname, there is NO WAAY for us to provide them with a valid SSL cert. that will not pop up these annoying w
Re: (Score:2)
Encryption without authentication only defends against people who can eavesdrop but not perform MITM. Unless you have set up static ARP records throughout your network, anyone who can eavesdrop can also perform MITM and trivially break your encryption. Who then is encryption going to defend against
Re: (Score:1)
Re: (Score:1)
It is absolutely not an SSL problem. SSL is a cryptographic protocol; HTTPS is the secure web protocol (actually, I don't think there's an official name for SSL+HTTP).
well, I guess SSL may be partially responsible, but you make the implication that SSL was only ever intended for the
Re: (Score:2)
Re: (Score:2)
As a minor issue, the SSL key is sent during the connection set up, before the client can send a Host: header. This means that each host wishing to employ HTTPS has to have its own IP address - otherwise, the server doesn't know which key to use.
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 [cacert.org] (called CN+subjectAltName). I don't know if this method is the one you referred to below:
There's actually a way around this: HTTP 1.1 specifies how to upgrade a connection to HTTPS, which can be done after the Host: header has been sent. Unfortunately, a lot of software appears not to support this feature.
Re: (Score:2)
Self sign your own certs.
If google [google.com] and paypal [paypal.com] can't get it right why should anybody else care?
all people should care about is it's encrypted. Do you REALLY believe CA's check who you are?
A previous posting regarding cert keys hit the nail on the head.
Re: (Score:2)
You're right. It would make more sense to have no "accept this certificate popup at all" and to create a new "encrypted but not authenticated" icon to replace the lock.
Re: (Score:2)
So now you can rest safe in the knowledge that you are either communicating directly with your bank or directly with some scummy phisher? That's such a useful thing to know! (It was said earlier, but it bears repeating: SSL encryption without authentication is useless, and this is because attackers are not always just passive eavesdroppers.)
Re: (Score:2)
False. It prevents passive eavesdropping attacks.
The question here is very simple: How should the browser treat a self-signed certificate or a certificate signed by an unknown CA? There are four choices: 1.) Pop up a scary warning 2.) Treat it like a PKI-authenticated page 3.) Treat it like any normal HTTP page. 4.) Give it its own "encrypted/not authenticated" icon.
Option 2 is obviously wrong. The page can't be authenticated cryptographically, so we can't
Debate? What debate? (Score:3, Insightful)
Good UI idea, bad (but improved) cert idea (Score:4, Interesting)
The user interface aspect of this is a good idea. One of the bad things about x.509 up to now is that it's all-or-nothing; the other side's identity is either completely trusted or not trusted at all. Real life isn't like that, as pgp took into account a decade and a half ago. Acknowledging that there is a degree to which the other side has been authenticated, and then showing this in the browser, is a step in the right direction. I enthusiastically approve of this change to browser UIs.
On the non-UI front, things are a little less encouraging, but it's still a slight improvement (but with a dark side). It is a fact of reality that an identity certifier has limited resources and no matter what they do, they can be fooled. Letting the certifier put something into the cert to indicate how hard they tried to authenticate, is a good thing. When I sign someone's pgp key, it's good that I can indicate degree of trust; casual trust if all I did was look at someone's government-issued photo id, and strong trust if I actually know the person I'm signing (i.e. a fake ID wouldn't be enough to fool me). I am pleased that the x.509 system now has some sort of way to do this.
It's still unfortunate that they left the biggest weakness in the system, though. An identity is still only certified by one certifier. That's really dumb. Verisign can be fooled, Thawte can be fooled, I can be fooled, but fooling all 3 of us at the same time is a bigger feat, so that would be a great way to improve the amount by which an identity can be believed. That's something that pgp also figured out a decade and a half ago, but x.509 hasn't caught up.
But that leads to the dark side. I think there is a reason the system doesn't support multiple signers: it makes it easier for new CAs to enter the certifying "market", and also could lead users to think about how much they trust the big brand name certifiers. Suppose I claim to meet Amazon's keymaster and I sign their cert. The issue that 99.99% of users would face, upon seeing my signature on Amazon's key, is that they don't have the foggiest idea of who the hell I am or why they should trust me, so they would go into their software and make sure their trust level for me is zero (or really really close to zero). Actually that would be the default. But then it strikes the user: "Wait a minute, how much do I trust Verisign? I don't know any more about them, than I know about Sloppy." So the user then goes into their software and also sets Verisign to a low value. The user should only really trust people they have reason to trust. They probably wouldn't really delete Verisign from their list, but they'd set the trust level to very low. Probably not zero, as there's some "sheep factor" faith level in a big brand name. But the whole issue of thinking about who you trust and to which degree, would be a major threat to the brand name CAs.
I understand why Microsoft is willing to play along with the big CAs. I don't understand why the Mozilla, Konqueror, Safari, etc teams do. Supporting a multiple-certifier system (e.g. OpenPGP) would improve those browers with no apparent downside.
MOD PARENT UP (Score:2)
Re: (Score:2)
This is because x.509 was designed for the Directory Access Protocol (x.500) which is entirely hierarchical and has no room for uncertainty or rival authorities.
This still says nothing about trustworthin
Entrust's SSL certificate, and its problems (Score:5, Insightful)
Domain: www.entrust.com
Server identity:
CN = www.entrust.com
serialNumber = DOC:19961216
OU = it
O = Entrust Inc
jurisdictionOfIncorporationStateOrProvinceName = MD
jurisdictionOfIncorporationCountryName = US
L = Ottawa
ST = Ontario
C = CA
Issuer identity:
CN = Entrust Certification Authority - L1A
OU = (c) 2006 Entrust, Inc.
OU = www.entrust.net/CPS is incorporated by reference
OU = CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND LIABILITY
OU = AND ADDITIONAL TERMS GOVERNING USE AND RELIANCE
O = Entrust, Inc.
C = US Certificate has 10 extensions.
The CA Browser Forum has published a standard for these certificate. [cabforum.org] So that's what we go by.
How do you tell this is an Extended Validation certificate? That's not in the CA Browser Forum's standard. It's dependent on the certificate issuer.
It's documented, on Entrust's web site [entrust.net] "Each EV SSL Certificate issued by the Entrust EV SSL CA to a Subscriber contains an Object Identifier (OID) defined by the Entrust EV SSL CA in the certificate's certificatePolicies extension ... which
by pre-agreement with Application Software Vendors, marks the certificate as being an EV SSL Certificate.
The following OID has been registered by the Entrust EV SSL CA for inclusion in EV SSL Certificates: 2.16.840.1.114028.10.1.2"
That OID number appears in the middle of a comment in the certificatePolicies extension. So, for each issuer, you have to look for something different.
The certificate checker has to be really careful. To verify that a certificate is an Extended Validation certificate, it's not enough to find that OID. You have to make sure that the certificate was issued by the issuer entitled to use that OID. Otherwise, it's easy to forge these certificates.
But if you're too thorough in the checking, the certificate bounces. The whole point of an Extended Validation certificate is to validate the company's identity. So we have the new fields "serialNumber", "jurisdictionOfIncorporationStateOrProvinceName", and "jurisdictionOfIncorporationCo
Re: (Score:1)
Re: (Score:2)
No, the spec says, on page 9:
Registration Number:
Certificate Field: Subject:serialNumber (OID 2.5.4.5)
Required/Optional: Required
Contents: This field MUST contain the unique Registration Number assigned to the Subject by the Incorporating Agency in its Jurisdiction of Incorporation (for Private Organization Subjects only).
So when you go to validate the certificate against incorporation records, it bounces.
The whole point of Extended Validation certificates was that the organization was supposed
Re: (Score:2)
Since there's no public OID list for these certificates, I've added one to the Wikipedia entry for Extended Validation Certificates. [wikipedia.org] Entrust, Verisign, and Comodo are filled in; if you can find the documented values for other vendors, please add them. Thanks.
not first (Score:1)
SSL Certs are ridiculous. (Score:2)
Re: (Score:1)
SRP6a would be better (Score:2)
SRP is a password-based system, rather than a key-based system. SRP validates not just that the client knows the password, but that the server knows the password (hash), all the while not revealing anything useful to an eavesdropper or a man in the middle. It uses the password to establish a shared secret (session key) between the client and server for further communication.
It
Microsoft (Score:2)
* write insecure products that people cannot fix themselves
* delay patching their insecure products
* try to prevent SOA/REST from emerging quickly; relying on obscene vendor lockin for revenue
* build and use languages that promote and maintain poor programmming practices
They are the prototypical entrenched power monger, and they continue to pollu