Byte order would only matter if the data consisted of multi-byte characters. While one might think that 0D0A is a multi-byte newline, it's really a two-character combination (CR+LF) that together mean a logical newline. I really doubt the Acorn is using multi-byte characters here where byte ordering mattered.
Byte ordering is really a subject of encoding, though, and not something XML is supposed to have to worry about, though XML does allow for a prologue of sorts to allow parsers to "figure out" byte ordering for cases when they are using multi-byte characters.
I believe MacOS also used a newline convention of 0A0D.
I have never had this problem and have been generating XHTML content for years on several browser types. Could you elaborate on what browser and version you saw this behavior? Was your web server delivering a proper MIME type? Could your browser have been IE, which second-guesses generic MIME types? It's possible you have a misconfiguration and just don't realize it because IE tries to play smart.
XML 1.0 and XML 1.1 require that parsers normalize what they consider "new lines" to a standard 0x0a newline character. For those applications where whitespace and newlines are somewhat significant, on those platforms that use a native newline other than what XML 1.0 allowed as a newline character, you had to create a hacked up "binary" file. In other words, you could not create this file as a text file on that platform, because the newlines would be treated as arbitrary binary data in the actual XML document and would not get normalized.
All this change does is tells XML 1.1 parsers to recognize this Unicode newline as another valid newline, so that when it normalizes newlines in the XML data, it knows to honor this one as well. This lets people on those IBM mainframe platforms store XML as a native text document instead of trying to hack up something that is unmaintainable except through specialized tools. Unless people are doing stupid/incorrect stuff with their character sets and encodings, this should not affect anyone else.
There's a reason XML supports multiple types of newlines: because there are platforms out there that use those other types of newlines. XML 1.1 standardizes on a 0x0a newline, but recognizes that there are other types out there, and requires parsers to normalize this before parsing the XML. All the specification is doing is adding another type of newline that a fairly popular platform uses. This is no different than adding MacOS-specific and Windows-specific newline types to XML in the first place. The goal is to allow platforms to store XML data as a native text document instead of forcing newlines that cause XML documents to be treated as awkward binary data on those platforms that don't have XML-compatible newline conventions.
This whole thread is retarded. Few people posting all of this FUD seem to know the difference between a character encoding, a character set, and a pimple on their ass. This change in XML 1.1 changes nothing for anyone, except those that want to write XML 1.1 parsers and those on platforms that use this Unicode newline as their native newline character.
If we're going to throw up such a fuss about this one addition (which in NO way breaks ANY existing XML 1.0 documents), why aren't we throwing up a fuss about including MacOS or Windows newlines into XML in the first place? GET RID OF THEM ALL! UNIX NEWLINES ARE THE ONLY TRUE NEWLINES!!#!!@#$
You apparently do not frequent some of the mailing lists I do. Be aware that this particular brand of software may not be the only kind out there. This form of spam has been directly observed being delivered through an RPC connection.
Ignore my other message. As anyone with any security experience whatsoever should be telling people, you should be blocking everything you do not explicitly need anyway. Don't tell people to just block UDP on port 137 and 138, and TCP on port 139. They should be blocking everything to begin with, and they should be aware that this type of spam can come in through the standard messenger front-door on UDP/138 as well as through RPC on 135, in case they think about opening up these ports to the public in the future.
I was genuinely shocked at how rude consular employees are. It's the jail-guard syndrome, where jobs that give people power encourage the petty tyrant within.
While I don't doubt your experiences here, keep in mind also that a sizable percentage of the people going to see the consulate are not in a very good mood either.
With the big push for "paperless" agencies nowadays, why don't we have a real good slash-style public comment forum in place yet? Sure, many agencies accept e-mails in addition to more traditional forms of public comment, but one might think that a true online web-based public forum might be desirable for situations where government agencies wish to solicit public comment. That way we can see other posts, respond to them, have intelligent discussion where necessary, and the agencies wouldn't be limited to simply re-reading the same things over and over again, trying to pick out a gem here and there, but otherwise just tallying votes.
I would ask you to name why it's objectively good.
Personally? Survival of the species. Earth is a "single point of failure" for us. One good whack from another stellar body (which will happen), assuming we don't destroy ourselves first, and we are all extinct.
The free market is only good for coming up with the best ways of moving money. This is why forms of government are generally independent from forms of economy. Government has to be there to decide what the people, as a group want to do. The free market relies on the acts and decisions of individuals spending their money in different ways.
It only "requires" it if the user wishes to listen to the digital broadcasts. I haven't heard anything that suggests they're going to be doing away with analog radio broadcasts any time in the near future, certainly not within the next 10 or 15 years. That's a lot of time for prices to come down.
I don't think I agree with this sentiment. The space industry would not be an industry without government stepping in and jump starting it. Look where we are with private rocket launches and only now plans for the first private trip to the moon.
Likewise, HDTV is a technology (for instance) that would have simply never taken off in the US. Content suppliers don't want to make the investment because there's no demand for it, manufacturers can't streamline and drop prices until there's demand for it, and consumers aren't demanding it because there's no content and the prices are too high. Without someone forcing these things to happen, the free market has spoken: they'll never happen in the US.
While some people (perhaps you) are fine with that, I personally would rather there be something driving innovation when there's a clear benefit but stupid free market short-falls keep progress from being made. The free market economy is not perfect.
Some phone systems actually offer a "caller ID blocking blocker" service, where if a user is deliberately blocking their caller ID information and they call you, they get a recording saying that you do not accept calls from anonymous numbers and offers them the chance to either unblock their number for that call, or hang up.
This is a bit different from Privacy Manager or other services which intercept any unidentified call.
In Missouri, it is illegal for telemarketers to mask their caller ID information like that, though that doesn't stop them from basing there calls in an area that caller ID information doesn't get sent from (so they appear as "Unavailable" or "OUT OF AREA", depending on your equipment). But the moment you get one from "Private", that's illegal.
I used to receive at least 1-2 telemarketing calls a week. After adding myself to Missouri's "no call" list, I haven't received a single telemarketing call in 6 months or so.
This is the most effective measure, in my opinion, without irritating the hell out of family and friends that may live in an area that does not send caller ID information (such that they show up as "OUT OF AREA").
Privacy Manager is a fairly rude piece of technology. It works, but I get quite a lot of legitimate calls sent through the system as well and I know they don't like it.
As such, it shouldn't matter whether I have one, ten or a hundred DNS names associated with my website and with my organization. By forcing you to buy separate certificates for your web server's DNS name, your mail server's DNS name, your LDAP server's DNS name and others, they are extracting even more money from your wallet.
SSL certificates are solely intended to certify the authenticity of a DNS hostname. I also think it's a sham to be selling these for every single hostname. If I as an organization have administrative control over example.com, all I should have to do is buy a certificate that establishes my control over example.com. I should be able to take that certificate and sign sub-domains and hostnames under example.com and distribute those keys throughout my organization however I want to. Validation of those certificates would only extend to the domain name signed by the next certificate up the chain, so I can't just sign www.microsoft.com using my example.com certificate, but it leaves complete control over establishing the authenticity of hosts and sub-domains under my domain to me, which is where it should be.
If it were up to me, SSL certificates would be issued for every domain registration directly from the registrars. Browsers wouldn't trust arbitrary certificate authorities, they'd trust the certificate created for the root DNS zone, which would then be used to sign registrar certificates for the zones they control, and delegation (in DNS and certificates) would proceed from there.
The sole advantage to the system as I see it today is that there's fewer points of vulnerability. The big certificate signing authorities can afford to spend a ton of money securing their keys. But once you start delegating outward, every registrar responsible for the.com zone would have to protect their keys equally well. If one got compromised without them knowing, any.com certificate would be suspect (subject to revocation at a later date, obviously). In addition, if my subdomain.example.com key was compromised and a www.subdomain.example.com host was hijacked, an SSL user-agent would treat it as authenticated. Fortunately the damage would be limited to that subdomain.
When you'd set up an account or device for someone, you (the administrator) would link that account to the person's identity by requiring the user to possess a "certificate" for whatever assertion I want to key off of. This would generally be a link from my username to my real-world name or driver's license number or something, but could easily be linked to a person's job title or role, as signed by the company. The only way I would be granted access is by presenting this certificate just like we do with SSL today.
If I wanted to log into the telephone company's systems to pay my phone bill, I might not even need to assert my identity, I'd just have to assert my ownership of that phone number, via a certificate that the phone company would have granted to me upon assignment of the number.
All of these would presumably go on a fat smart card of some kind, a virtual key ring.
The actual act of authentication would work with data personally signed by you. If you sign the assertion that basically means "this voice print pattern is my own", any voice authentication mechanism in the world, provided they can validate the certificate chain establishing your identity, will be able to say, "this voice print I just heard matches the voice print asserted by this certificate" and it will allow them access. You've used your own private secret key along with your identity certificate to sign that voice print. It's up to the voice print analyzer to then do a good job of matching it up to something.
Now, this isn't to say that the technology itself isn't flawed. If it has a 5% error rate, that's still a 5% error rate, but that's not a flaw in the system of establishing that voice print assertion. Whoever's relying on that voice print authentication system to provide a level of authentication is doing so knowing the risks.
Actually, I can still see an argument against allowing users to sign something like a voice print. That might be something your local government might have to do on your behalf. Otherwise I could sell the use of my certificate for some other guy's voice if he wanted to get into something he'd otherwise be barred from. *shrug*..
How is any of this limited to the United States? Are you saying you do not obtain certification of identity from whatever local government you participate in?
In other words, we need a much more hierarchial delegation of "trust" rooted in the roots of each resource model we're worried about. For "legal identity" we have the electronic equivalents of passports, state ID's and corporate charters. For "DNS identity" we'd have to start something at ICANN and delegate to registrars and second-level domain owners. A trivial extension of that allows for "e-mail identity". A certified telephone number assertion might come from a telephone company. We'd then just need a nice mechanism to merge all of these together as needed.
The SSL world today basically revolves around a single type of assertion: a best effort identity verification and DNS. This is too flat.
This is the situation where we need the government to step in. We're all getting driver's licenses from the government, passports, etc., and these are really the only real-world pieces of identification people accept. What we need is for the government to step in and issue digital ID's, to individuals and corporations. These ID's would tie us to whatever electronic identifiers are appropriate (domain names and/or e-mail addresses), and appropriate delegation would be permitted from there.
We just need the a trusted authority (for certain definitions of 'trusted' and for the definition of 'authority' that is ubiquitously recognized instead of decided by the highest bidders in the browser wars) to make digital assertions.
You'd start with certifying identities: my state might sign a certificate certifying my name, maybe driver's license number, perhaps address and even a photograph. I should now be able to sign e-mails with this now independently of my e-mail address. The resulting signed message could carry whatever signed assertions I wanted to put on it. (Probably my name and maybe my photograph.) I can't forge these, because these components are signed by the state in connection with my identity. A posting to a self-help group might just assert my identity in the form of a photograph and an unsigned nickname.
Taking this a step further, I should be able to use this ID to sign other things, even web sites. This will require changes to the way users perceive an "authenticated" web site. If I go to a bank at www.example.com today, they have a certificate that basically states "www.example.com is Example Bank, and their identity is certified". What my own signed web site might assert is "www.example.com is Joe User". User agents need to give more weight to the name here and less weight to the fact that the domain name matches what's in the certificate.
Extend this now to corporations. When a corporate charter is created, a digital ID for that corporation is created along with it and signed by the state of incorporation. That corporation can now sign assertions like "Joe User is the CEO of Example Corporation".
So now, when Joe User sends an e-mail, he can include this information:
Joe User (signed by the state of residence)
(Joe's picture, signed by the state)
Job Title: CEO (signed by Example Corporation)
At this point, we really have a framework to allow the signing of most any type of assertion. If someone feels that we still need a signed DNS-based model, we'd do this within the DNS framework. I.e. registrars, when creating a domain, would also create a certificate for the domain name created and pass that on to the new owner, who can now sign for sub-domains as needed. When presented with www.sub.example.com, we have "www" signed by "sub" signed by "example" signed by one of the registrars for ".com".
Some of these concepts will require a re-thinking of the way we approach authenticated online identities. We need to stop placing so much importance on online identifiers (like domain names and e-mail addresses) and start paying attention to who is making those assertions. I can sign an assertion stating that my e-mail address is 'joe@example.com', but unless that's really my e-mail address, it's not going to do anyone a whole lot of good. If I go around forging e-mails from joe@example.com and including that signed assertion, everyone should be able to take one look at that and say, "Who the hell is this guy claiming to be joe@example.com?". Only the guy with the certificate stating the assertion that he is "joe", signed by "example", signed by a valid registrar for ".com" would be able to say that with any authority.
A lot of this can be done today with signed/encrypted XML, provided we have a common framework to start sharing the assertions.
It's not libel either. This "CEO" didn't start going around telling newspapers and buying TV spots saying this guy was an evil hacker spreading viruses. He reported the information he had to the FBI and, from what we can assume, contacted the guy himself.
There's no slander or libel going on here. There are no statements of fact published anywhere by this CEO defaming this guy.
In addition, the post I was replying to was discussing this in the context of seeking compensation. General damages are not usually awarded in cases of libel unless the false statements were published maliciously. I really think the "CEO" here just didn't understand that the address was forged. There's no malice here in these statements.
I'd say this fellow was slandered and lost some serious face.
Uh, how is this slander?
slander n. oral defamation, in which someone tells one or more persons an untruth about another, which untruth will harm the reputation of the person defamed....
I can walk up to you and suggest that you do all sorts of depraved and evil things, but until I start going around to other people and getting them to think you're some kind of freak, you have no basis to say you've been "slandered".
Slashdot Mirror
Byte order would only matter if the data consisted of multi-byte characters. While one might think that 0D0A is a multi-byte newline, it's really a two-character combination (CR+LF) that together mean a logical newline. I really doubt the Acorn is using multi-byte characters here where byte ordering mattered.
Byte ordering is really a subject of encoding, though, and not something XML is supposed to have to worry about, though XML does allow for a prologue of sorts to allow parsers to "figure out" byte ordering for cases when they are using multi-byte characters.
I believe MacOS also used a newline convention of 0A0D.
I have never had this problem and have been generating XHTML content for years on several browser types. Could you elaborate on what browser and version you saw this behavior? Was your web server delivering a proper MIME type? Could your browser have been IE, which second-guesses generic MIME types? It's possible you have a misconfiguration and just don't realize it because IE tries to play smart.
XML 1.0 and XML 1.1 require that parsers normalize what they consider "new lines" to a standard 0x0a newline character. For those applications where whitespace and newlines are somewhat significant, on those platforms that use a native newline other than what XML 1.0 allowed as a newline character, you had to create a hacked up "binary" file. In other words, you could not create this file as a text file on that platform, because the newlines would be treated as arbitrary binary data in the actual XML document and would not get normalized.
All this change does is tells XML 1.1 parsers to recognize this Unicode newline as another valid newline, so that when it normalizes newlines in the XML data, it knows to honor this one as well. This lets people on those IBM mainframe platforms store XML as a native text document instead of trying to hack up something that is unmaintainable except through specialized tools. Unless people are doing stupid/incorrect stuff with their character sets and encodings, this should not affect anyone else.
There's a reason XML supports multiple types of newlines: because there are platforms out there that use those other types of newlines. XML 1.1 standardizes on a 0x0a newline, but recognizes that there are other types out there, and requires parsers to normalize this before parsing the XML. All the specification is doing is adding another type of newline that a fairly popular platform uses. This is no different than adding MacOS-specific and Windows-specific newline types to XML in the first place. The goal is to allow platforms to store XML data as a native text document instead of forcing newlines that cause XML documents to be treated as awkward binary data on those platforms that don't have XML-compatible newline conventions.
This whole thread is retarded. Few people posting all of this FUD seem to know the difference between a character encoding, a character set, and a pimple on their ass. This change in XML 1.1 changes nothing for anyone, except those that want to write XML 1.1 parsers and those on platforms that use this Unicode newline as their native newline character.
If we're going to throw up such a fuss about this one addition (which in NO way breaks ANY existing XML 1.0 documents), why aren't we throwing up a fuss about including MacOS or Windows newlines into XML in the first place? GET RID OF THEM ALL! UNIX NEWLINES ARE THE ONLY TRUE NEWLINES!!#!!@#$
Jesus, people...
Please see this post and other related posts in this mailing list for details about what exactly is being observed.
You apparently do not frequent some of the mailing lists I do. Be aware that this particular brand of software may not be the only kind out there. This form of spam has been directly observed being delivered through an RPC connection.
Ignore my other message. As anyone with any security experience whatsoever should be telling people, you should be blocking everything you do not explicitly need anyway. Don't tell people to just block UDP on port 137 and 138, and TCP on port 139. They should be blocking everything to begin with, and they should be aware that this type of spam can come in through the standard messenger front-door on UDP/138 as well as through RPC on 135, in case they think about opening up these ports to the public in the future.
Much of the Messenger spam is coming in through the RPC service on port 135. You'll want to block that or turn it off as well.
I was genuinely shocked at how rude consular employees are. It's the jail-guard syndrome, where jobs that give people power encourage the petty tyrant within.
While I don't doubt your experiences here, keep in mind also that a sizable percentage of the people going to see the consulate are not in a very good mood either.
With the big push for "paperless" agencies nowadays, why don't we have a real good slash-style public comment forum in place yet? Sure, many agencies accept e-mails in addition to more traditional forms of public comment, but one might think that a true online web-based public forum might be desirable for situations where government agencies wish to solicit public comment. That way we can see other posts, respond to them, have intelligent discussion where necessary, and the agencies wouldn't be limited to simply re-reading the same things over and over again, trying to pick out a gem here and there, but otherwise just tallying votes.
I would ask you to name why it's objectively good.
Personally? Survival of the species. Earth is a "single point of failure" for us. One good whack from another stellar body (which will happen), assuming we don't destroy ourselves first, and we are all extinct.
The free market is only good for coming up with the best ways of moving money. This is why forms of government are generally independent from forms of economy. Government has to be there to decide what the people, as a group want to do. The free market relies on the acts and decisions of individuals spending their money in different ways.
requires a new device on the listener's end
It only "requires" it if the user wishes to listen to the digital broadcasts. I haven't heard anything that suggests they're going to be doing away with analog radio broadcasts any time in the near future, certainly not within the next 10 or 15 years. That's a lot of time for prices to come down.
LET THE MARKET dictate what happens!
I don't think I agree with this sentiment. The space industry would not be an industry without government stepping in and jump starting it. Look where we are with private rocket launches and only now plans for the first private trip to the moon.
Likewise, HDTV is a technology (for instance) that would have simply never taken off in the US. Content suppliers don't want to make the investment because there's no demand for it, manufacturers can't streamline and drop prices until there's demand for it, and consumers aren't demanding it because there's no content and the prices are too high. Without someone forcing these things to happen, the free market has spoken: they'll never happen in the US.
While some people (perhaps you) are fine with that, I personally would rather there be something driving innovation when there's a clear benefit but stupid free market short-falls keep progress from being made. The free market economy is not perfect.
I have not had any telemarketing calls since signing up with it.
I've received 2 or 3 such advertisements via e-mail in the last few years. I thought it was somewhat ironic at the time. :(
Some phone systems actually offer a "caller ID blocking blocker" service, where if a user is deliberately blocking their caller ID information and they call you, they get a recording saying that you do not accept calls from anonymous numbers and offers them the chance to either unblock their number for that call, or hang up.
This is a bit different from Privacy Manager or other services which intercept any unidentified call.
In Missouri, it is illegal for telemarketers to mask their caller ID information like that, though that doesn't stop them from basing there calls in an area that caller ID information doesn't get sent from (so they appear as "Unavailable" or "OUT OF AREA", depending on your equipment). But the moment you get one from "Private", that's illegal.
I used to receive at least 1-2 telemarketing calls a week. After adding myself to Missouri's "no call" list, I haven't received a single telemarketing call in 6 months or so.
This is the most effective measure, in my opinion, without irritating the hell out of family and friends that may live in an area that does not send caller ID information (such that they show up as "OUT OF AREA").
Privacy Manager is a fairly rude piece of technology. It works, but I get quite a lot of legitimate calls sent through the system as well and I know they don't like it.
As such, it shouldn't matter whether I have one, ten or a hundred DNS names associated with my website and with my organization. By forcing you to buy separate certificates for your web server's DNS name, your mail server's DNS name, your LDAP server's DNS name and others, they are extracting even more money from your wallet.
.com zone would have to protect their keys equally well. If one got compromised without them knowing, any .com certificate would be suspect (subject to revocation at a later date, obviously). In addition, if my subdomain.example.com key was compromised and a www.subdomain.example.com host was hijacked, an SSL user-agent would treat it as authenticated. Fortunately the damage would be limited to that subdomain.
SSL certificates are solely intended to certify the authenticity of a DNS hostname. I also think it's a sham to be selling these for every single hostname. If I as an organization have administrative control over example.com, all I should have to do is buy a certificate that establishes my control over example.com. I should be able to take that certificate and sign sub-domains and hostnames under example.com and distribute those keys throughout my organization however I want to. Validation of those certificates would only extend to the domain name signed by the next certificate up the chain, so I can't just sign www.microsoft.com using my example.com certificate, but it leaves complete control over establishing the authenticity of hosts and sub-domains under my domain to me, which is where it should be.
If it were up to me, SSL certificates would be issued for every domain registration directly from the registrars. Browsers wouldn't trust arbitrary certificate authorities, they'd trust the certificate created for the root DNS zone, which would then be used to sign registrar certificates for the zones they control, and delegation (in DNS and certificates) would proceed from there.
The sole advantage to the system as I see it today is that there's fewer points of vulnerability. The big certificate signing authorities can afford to spend a ton of money securing their keys. But once you start delegating outward, every registrar responsible for the
When you'd set up an account or device for someone, you (the administrator) would link that account to the person's identity by requiring the user to possess a "certificate" for whatever assertion I want to key off of. This would generally be a link from my username to my real-world name or driver's license number or something, but could easily be linked to a person's job title or role, as signed by the company. The only way I would be granted access is by presenting this certificate just like we do with SSL today.
If I wanted to log into the telephone company's systems to pay my phone bill, I might not even need to assert my identity, I'd just have to assert my ownership of that phone number, via a certificate that the phone company would have granted to me upon assignment of the number.
All of these would presumably go on a fat smart card of some kind, a virtual key ring.
The actual act of authentication would work with data personally signed by you. If you sign the assertion that basically means "this voice print pattern is my own", any voice authentication mechanism in the world, provided they can validate the certificate chain establishing your identity, will be able to say, "this voice print I just heard matches the voice print asserted by this certificate" and it will allow them access. You've used your own private secret key along with your identity certificate to sign that voice print. It's up to the voice print analyzer to then do a good job of matching it up to something.
Now, this isn't to say that the technology itself isn't flawed. If it has a 5% error rate, that's still a 5% error rate, but that's not a flaw in the system of establishing that voice print assertion. Whoever's relying on that voice print authentication system to provide a level of authentication is doing so knowing the risks.
Actually, I can still see an argument against allowing users to sign something like a voice print. That might be something your local government might have to do on your behalf. Otherwise I could sell the use of my certificate for some other guy's voice if he wanted to get into something he'd otherwise be barred from. *shrug*..
How is any of this limited to the United States? Are you saying you do not obtain certification of identity from whatever local government you participate in?
In other words, we need a much more hierarchial delegation of "trust" rooted in the roots of each resource model we're worried about. For "legal identity" we have the electronic equivalents of passports, state ID's and corporate charters. For "DNS identity" we'd have to start something at ICANN and delegate to registrars and second-level domain owners. A trivial extension of that allows for "e-mail identity". A certified telephone number assertion might come from a telephone company. We'd then just need a nice mechanism to merge all of these together as needed.
The SSL world today basically revolves around a single type of assertion: a best effort identity verification and DNS. This is too flat.
We just need the a trusted authority (for certain definitions of 'trusted' and for the definition of 'authority' that is ubiquitously recognized instead of decided by the highest bidders in the browser wars) to make digital assertions.
You'd start with certifying identities: my state might sign a certificate certifying my name, maybe driver's license number, perhaps address and even a photograph. I should now be able to sign e-mails with this now independently of my e-mail address. The resulting signed message could carry whatever signed assertions I wanted to put on it. (Probably my name and maybe my photograph.) I can't forge these, because these components are signed by the state in connection with my identity. A posting to a self-help group might just assert my identity in the form of a photograph and an unsigned nickname.
Taking this a step further, I should be able to use this ID to sign other things, even web sites. This will require changes to the way users perceive an "authenticated" web site. If I go to a bank at www.example.com today, they have a certificate that basically states "www.example.com is Example Bank, and their identity is certified". What my own signed web site might assert is "www.example.com is Joe User". User agents need to give more weight to the name here and less weight to the fact that the domain name matches what's in the certificate.
Extend this now to corporations. When a corporate charter is created, a digital ID for that corporation is created along with it and signed by the state of incorporation. That corporation can now sign assertions like "Joe User is the CEO of Example Corporation".
So now, when Joe User sends an e-mail, he can include this information:
- Joe User (signed by the state of residence)
- (Joe's picture, signed by the state)
- Job Title: CEO (signed by Example Corporation)
At this point, we really have a framework to allow the signing of most any type of assertion. If someone feels that we still need a signed DNS-based model, we'd do this within the DNS framework. I.e. registrars, when creating a domain, would also create a certificate for the domain name created and pass that on to the new owner, who can now sign for sub-domains as needed. When presented with www.sub.example.com, we have "www" signed by "sub" signed by "example" signed by one of the registrars for ".com".Some of these concepts will require a re-thinking of the way we approach authenticated online identities. We need to stop placing so much importance on online identifiers (like domain names and e-mail addresses) and start paying attention to who is making those assertions. I can sign an assertion stating that my e-mail address is 'joe@example.com', but unless that's really my e-mail address, it's not going to do anyone a whole lot of good. If I go around forging e-mails from joe@example.com and including that signed assertion, everyone should be able to take one look at that and say, "Who the hell is this guy claiming to be joe@example.com?". Only the guy with the certificate stating the assertion that he is "joe", signed by "example", signed by a valid registrar for ".com" would be able to say that with any authority.
A lot of this can be done today with signed/encrypted XML, provided we have a common framework to start sharing the assertions.
It's not libel either. This "CEO" didn't start going around telling newspapers and buying TV spots saying this guy was an evil hacker spreading viruses. He reported the information he had to the FBI and, from what we can assume, contacted the guy himself.
There's no slander or libel going on here. There are no statements of fact published anywhere by this CEO defaming this guy.
In addition, the post I was replying to was discussing this in the context of seeking compensation. General damages are not usually awarded in cases of libel unless the false statements were published maliciously. I really think the "CEO" here just didn't understand that the address was forged. There's no malice here in these statements.
Uh, how is this slander? I can walk up to you and suggest that you do all sorts of depraved and evil things, but until I start going around to other people and getting them to think you're some kind of freak, you have no basis to say you've been "slandered".