Hi,
b) if Onion addresses have 2+ forms, one like the current (www.4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.onion) and the other being apparently more human-usable because it contains a CRC, the one which allows access to websites will win.
What if they both allow access to websites?
I had always thought that prop#279 addresses would be translated into their canonical forms before the browser acts on them. But the current proof-of-concept implementation would include them in the Host header, because the translation is done at the Tor layer (not the browser layer).
This also makes a mess of security certificates. (Or it means that both names would need to be in the certificate.)
And there's the issue of having two names for the same site.
My expectation to date has been that the problem with "4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad" is that that there is no place for the eyeball to rest when typing it in; as such I've presumed that a canonical form, defined by Tor, would be something like:
https://www.4acth47i-6kxnvkew-tm6q7ib2-s3ufpo5-sqbsnzjp-bi7utij-cltosqem-ad....
...being N groups of M characters (where N and M can be argued, feel free...)
That's not what's specified right now, and it not what will be released in 0.3.2 in a few weeks.
But we could implement a grouping and checksum mechanism like this using a prop#279 plugin, much like the bech transform.
Depending on where we do the name translation, this change would cause the same Host header and certificate issues.
The advantage of a system like this is that it's not perfect, but a typo mostly has to happen twice and be quite fortunate to go undetected. Of course it's not perfect, but nothing will be, and clever selection of checksum and encoding will result in something which is still DNS- and Browser-compliant.
One other advantage: a DNS-format-compliant checksum like this could be trivially baked into an SSL certificate without requiring CA/Browser Forum to invent a wholly new kind of certificate just-for-Tor
This is true. We should make any schemes DNS-compliant, which is how the examples in prop#279 work.
This would result in Prop224 Onion Addresses which would not only be typo-resistant, but could also continue to be issued with EV certificates where site-attestation is beneficial.
Further: adding segment-checksum bits at the end would be (I think?) backwards compatible with existing Prop224 addresses.
They would be compatible, as would most prop#279 addresses, apart from the issues mentioned above.
Are you aware that there's already a checksum in v3 onion service addresses?
"The onion address of a hidden service includes its identity public key, a version field and a basic checksum."
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n2012
T