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.onion/
...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
like this using a prop#279 plugin, much like the bech transform.
would cause the same Host header and certificate issues.
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,