<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I share Ryan's concerns. I find it deeply troubling that a member
of this Forum, whose representative is the current Forum Chair, and
which had no small part in drafting the BRs and seeing them through
to adoption is willfully issuing certificates in direct
contravention of the Requirements. None of us is perfect, but as
head of validation for Comodo I make every effort to ensure that
certificates issued by Comodo are fully compliant with the BRs and
EV Guidelines, business expediency notwithstanding.<br>
<br>
In checking through certlint to try to find certificates issued with
improperly formatted IP addresses, in order that I might better
understand this issue, imagine my surprise to find several wildcard
certificates, also issued by Symantec, and also in direct
contravention of the BRs:<br>
<br>
lab-rct-*.us.kworld.kpmg.com<br>
lab-rct-*.us.kpmg.com<br>
rct-*.us.kpmg.com<br>
<br>
See: <a
href="https://crt.sh/?cablint=65&iCAID=1449&opt=cablint">https://crt.sh/?cablint=65&iCAID=1449&opt=cablint</a><br>
<br>
The BRs state, in definitions section:<br>
<br>
<b>Wildcard Certificate:</b> A Certificate containing an asterisk
(*) in the <b>left-most position</b> <i>[emphasis mine] </i>of
any of the Subject Fully-Qualified Domain Names contained in the
Certificate.<br>
<br>
Regards,<br>
Rich Smith<br>
Validation Manager<br>
Comodo<br>
<br>
<div class="moz-cite-prefix">On 4/21/2016 8:23 AM, Ryan Sleevi
wrote:<br>
</div>
<blockquote
cite="mid:CACvaWva+HWtObv=EJaHpkdB3E1T+kDHSTdfKctRYG6WzikopxA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Apr 21, 2016 at 6:13 AM, Jody
Cloutier <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jodycl@microsoft.com" target="_blank">jodycl@microsoft.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div
style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">Ryan,
I'm not sure I understand why Google is so intent on
this new course of public shaming on this matter and
others currently under discussion, but if it helps to
do the right thing, then fine. The fact is that the
requirement was not addressed, and we need to figure
out how to fix the issue for all of our customers.
Microsoft has addressed this in Windows 10, but we are
not currently planning on back-porting this change to
previous operating systems. As such, this change is
needed or all of our customers will be affected. </div>
</div>
</blockquote>
<div><br>
</div>
<div>Jody,</div>
<div><br>
</div>
<div>Symantec has 8 months to investigate a solution that
doesn't require violating the BRs nor require violating
RFC 5280. They've admitted, by Rick, that they've instead
chosen to continue to violate the BRs, and are looking to
change the BRs to retroactively make this behaviour
acceptable. That is unquestionably deserving of censure,
on its own merits, regardless of the option.</div>
<div><br>
</div>
<div>Had Symantec shown that the solution provided to them -
which would have functioned properly for all Microsoft
users - was not in fact viable, in a timely fashion, and
for reasons they could explain, that's certainly worthy of
consideration. But that's clearly not the case here, and
that's unacceptable behaviour for a publicly trusted CA.</div>
<div><br>
</div>
<div>The burden of demonstrating why the proposed solution
doesn't work should exist with Symantec: They're the only
one that can speak to their customers needs, they're the
only ones who can investigate the technical viability (as
a publicly trusted CA), and they're the only ones who can
speak as to why such a solution may not be possible. If
the reasons are "because we don't want to", that should
seriously inform the response to a ballot, but if there
are reasons such as "This doesn't work for reason X", then
that could be a meaningfully compelling reason.</div>
<div><br>
</div>
<div>However, the idea that a Forum member would actively,
intentionally, and knowingly violate the BRs in order that
they may continue to sell certificates to customers,
participating in defining standards that their competitors
are obligated to follow but which they themselves do not
intend to, and potentially profiting off the customers for
which their competitors are obligated to refuse but for
which they will clearly accept (in contravention of the
BRs), speaks seriously to acting in bad faith and in an
anti-competitive manner. And that's deeply troubling.</div>
<div><br>
</div>
<div>To be clear: The censure is for the behaviour, not for
the proposal. Given that this proposal was raised in the
past, addressed in the past, and in the 8 months sense,
either no good-faith effort was put forward OR no
good-faith effort is communicated, is a serious and
egregious breach of public trust, and thus deserving of
strong and direct response, because if that pattern is
practiced and encouraged, it undermines and eliminates any
value in the Forum itself.</div>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>