<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Calibri">Hello, <br>
<br>
I am quoting below, with the author's permission, the reply I got
from Will Dormann after I enquired CERT about why we (and several
other CAs as well) are listed as "affected" by that problem. <br>
<br>
I do not agree with our company being listed as "affected", as our
CPS does not allow non-whitelist email addresses. However, Will's
rationale is that - regardless of the BRs - domain validation by
email is a security problem in itself, even when only whitelisted
email addresses are used:<br>
<br>
-----BEGIN QUOTE-----</font><br>
<pre wrap="">Hi Adriano,
Thanks for the feedback. We've been debating the concept of how to
list the varios root CAs. One stance is that email alone is
insufficient to verify domain ownership. Consider the many sites that
offer email services to end users. If a single host fails to block
creation of a single "special" alias that can be used to register an
SSL certificate, then their site can be impersonated. This perhaps
isn't widely known as recent articles indicate:
<a class="moz-txt-link-rfc2396E" href="https://raymii.org/s/blog/How_I_got_a_valid_SSL_certificate_for_my_ISPs_main_website.html"><https://raymii.org/s/blog/How_I_got_a_valid_SSL_certificate_for_my_ISPs_main_website.html></a>
<a class="moz-txt-link-rfc2396E" href="http://arstechnica.com/security/2015/03/bogus-ssl-certificate-for-windows-live-could-allow-man-in-the-middle-hacks/"><http://arstechnica.com/security/2015/03/bogus-ssl-certificate-for-windows-live-could-allow-man-in-the-middle-hacks/></a>
One of the purposes of the vulnerability note is to raise awareness of
the situation (the existence of these special email addresses).
Alternatively, the vulnerability note could be scoped to only list CAs
that accept email aliases outside of those 5 addresses. Here are some
examples or root CAs and resellers that allow email addresses outside
of the 5 listed in the BR:
<a class="moz-txt-link-rfc2396E" href="http://certum.eu/certum/cert,offer_Commercial_SSL.dxml?MEDIA=pdf"><http://certum.eu/certum/cert,offer_Commercial_SSL.dxml?MEDIA=pdf></a>
<a class="moz-txt-link-rfc2396E" href="http://evssl.com.ua/docs/thawte/enroll_ssl123_eng.pdf"><http://evssl.com.ua/docs/thawte/enroll_ssl123_eng.pdf></a>
<<a class="moz-txt-link-freetext" href="https://www.thawte.com/assets/documents/guides/simplify-ssl-certificate-managem">https://www.thawte.com/assets/documents/guides/simplify-ssl-certificate-managem</a>
ent-enterprise.pdf>
<a class="moz-txt-link-rfc2396E" href="http://host.dynamicwebhost.net/features/approvedemail.htm"><http://host.dynamicwebhost.net/features/approvedemail.htm></a>
<a class="moz-txt-link-rfc2396E" href="https://www.geocerts.com/api_spec.pdf"><https://www.geocerts.com/api_spec.pdf></a>
<<a class="moz-txt-link-freetext" href="http://account.buyhttp.com/knowledgebase/753/Which-email-address-can-approve-SS">http://account.buyhttp.com/knowledgebase/753/Which-email-address-can-approve-SS</a>
L-certificate-order.html>
<a class="moz-txt-link-rfc2396E" href="https://www.onestepssl.com/onestepssl_validation_process.php"><https://www.onestepssl.com/onestepssl_validation_process.php></a>
<a class="moz-txt-link-rfc2396E" href="http://www.domainpurpose.com/ssl-faqs.htm"><http://www.domainpurpose.com/ssl-faqs.htm></a>
<a class="moz-txt-link-rfc2396E" href="http://kb.canvashost.com/?p=935"><http://kb.canvashost.com/?p=935></a>
snip
Or see variants of:
<<a class="moz-txt-link-freetext" href="http://www.google.com/search?q=">http://www.google.com/search?q=</a>"ssladmin%40yourdomain.com">
Where this gets tricky is determining which CAs to list as affected.
If a root CA currently accepts an email outside of the list of 5, then
that's straightforward. But what about when an SSL reseller lists
such an address? How can a reseller have the authority to say what is
valid proof of domain ownership, as it would seem that the upstream
root CA would be the one that performs the validation? What about
cases where a root CA has accepted a non-standard email address in the
past, but no longer does now? If I purchased a certificate in the
past where the CA was more lax, then that still leaves me with a valid
cert that can be used for impersonation / interception of traffic.
Currently, the note is scoped as the acceptance of email as proof of
domain ownership in general. Yes, we are aware that the Baseline
Requirements document
<a class="moz-txt-link-rfc2396E" href="https://cabforum.org/baseline-requirements-documents/"><https://cabforum.org/baseline-requirements-documents/></a> lists email
addresses that can be used for this purpose. Our stance currently is
that this BR document should perhaps be updated, and that email
addresses should not be used as proof. If ownership of a domain is
the question, then the proof should be something domain-related, such
as WHOIS or the creation of a DNS entry, in our opinion. Not email.
Thank you,
Will Dormann</pre>
<font face="Calibri">-----END QUOTE-----<br>
<br>
Adriano<br>
<br>
<br>
</font><br>
<div class="moz-cite-prefix">Il 30/03/2015 11:47, Sigbjørn Vik ha
scritto:<br>
</div>
<blockquote cite="mid:55191BC2.2070908@opera.com" type="cite">
<pre wrap="">Hi,
According to <a class="moz-txt-link-freetext" href="http://www.kb.cert.org/vuls/id/591120">http://www.kb.cert.org/vuls/id/591120</a>, some issuers use
non-whitelisted email addresses to verify domain ownership.
The only link to such is
<a class="moz-txt-link-freetext" href="http://account.buyhttp.com/knowledgebase/753/Which-email-address-can-approve-SSL-certificate-order.html">http://account.buyhttp.com/knowledgebase/753/Which-email-address-can-approve-SSL-certificate-order.html</a>
(sic), it is unclear how many issuers this affects.
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<i><span style="font-family: Serif">Adriano Santoni</span></i>
</div>
</body>
</html>