Nelson B Bolyard wrote:
Benjamin Smedberg wrote, On 2009-02-20 10:28:
[...] CA guidelines
Which (whose) guidelines? Are you referring to RFC 5280 section 7, or
to some other guidelines?
Mozilla's CA cert policy doesn't even mention this subject.
say that certificates should not be issued with homographic
characters that might cause confusion, and as far as we know these
guidelines are being followed.
By all CAs?[...]
Nelson and everyone else not knowing the details of this :
The problem is solved not at the CA level, but at the registry/TLD level.
By default, i18n is in the *disabled* state and the punycode is
displayed instead of the i18n domain name.
When the registry in charge of a given TLD states that it has a
homograph avoidance method in place that guarantees that nobody will be
able to obtain a dangerous i18n domain name, then punycode decoding is
allowed for that TLD.
See the detail of that policy here :
http://www.mozilla.org/projects/security/tld-idn-policy-list.html
When issuing a SSL server cert there is no need for a special checking
at the CA level, because nobody will first be able to obtain a dangerous
domain name within that TLD.
Writing the above was very useful for me, because it made me realize the
current problem is quite wider than just wildcard certificates.
The attack is possible even without a wildcard certificate.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
