Paul Hoffman wrote:
At 7:09 AM +0100 2/24/09, Kaspar Brand wrote:
Kyle Hamilton wrote:
Removal of support for wildcards can't be done without PKIX action, if
one wants to claim conformance to RFC 3280/5280.
Huh? Both these RFCs completely step out of the way when it comes to
wildcard certificates - just read the last paragraph of section
4.2.1.7/4.2.1.6. PKIX never did wildcards in its RFCs.
Which says:
Finally, the semantics of subject alternative names that include
wildcard characters (e.g., as a placeholder for a set of names) are
not addressed by this specification. Applications with specific
requirements MAY use such names, but they must define the semantics.
At 10:50 PM -0800 2/23/09, Kyle Hamilton wrote:
RFC 2818 ("HTTP Over TLS"), section 3.1.
RFC 2818 is Informational, not Standards Track. Having said that, it is also
widely implemented, and is the main reason that the paragraph above is in the
PKIX spec.
Just one thing : The use of a wildcard certificate was a misleading red
herring in the implementation of the attack.
What's truly broken is that the current i18n attack protection relies on
the checking done by the registrar/IDN, and that the registrar/IDN can
only check the second-level domain name component.
Once they have obtained their domain name, attacker can freely use the
third-level domain name component to implement any i18n attack they want
even if no wildcard certificate is authorized.
This is not to say that wildcard certificates are not bad, evil,
anything, but that nothing new has been truly brought about that by this
attack.
So talk about wildcard certificate all you want, but this is a separate
discussion from the discussion about the solution for this new i18n attack.
And the solution for it will not be wildcard certificate related, will
not be easy or obvious, and so needs to be discussed as widely as possible.
Also there will be no crypto involved in the solution, as it's not
acceptable to choose to just leave ordinary DNS user out in the cold
with regard to the attack. So it needs to be discussed on the security
group, not crypto.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
