<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
In the SAN section of the BRs it simply says, "Wildcard FQDNs are
permitted." To know WHAT is permitted you MUST look to the
definition, and the definition clearly states "...left most
position..." Clearly these certificates are non-compliant. And I
don't buy for second that that's not understood by anyone who has
participated in Forum discussions for any length of time.<br>
<br>
And have we devolved to the point that we're now creating and
editing requirements only to then go forth and have a competition to
see which CA can out-do the others in finding loopholes in them? Is
that what this Forum has become? If so, then what are we doing
here? Let's shutter the place and walk away. <br>
<br>
The IP address certs that started this discussion aren't even a
loophole. They are specifically and clearly non-compliant. Now I'm
not a lawyer, but I do view the action of issuing them as
anti-competitive. I've had specific cases wherein I couldn't issue
EV certificates to labor unions in the U.S. for YEARS because the
wording in the EV Guidelines at the time did not allow for them. I
came here, I advised the Forum of my plight, and asked for a
solution. No one disagreed that they clearly legally existed as an
organization, but the solution was caught up in haggling over
minutiae for YEARS before a suitable change to the Guidelines was
officially adopted. I didn't just go ahead and issue the
certificates anyway, I waited for the Forum to arrive at a consensus
and fix the problem. And as a participant in good faith here,
that's what I expect of other participants.<br>
<br>
-Rich<br>
<br>
<div class="moz-cite-prefix">On 4/21/2016 12:54 PM, Jeremy Rowley
wrote:<br>
</div>
<blockquote
cite="mid:52lb822qwsdos07vbwhhjhde.1461261247705@email.android.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta content="text/html; charset=iso-8859-1">
<div>
<div>We don't issue these certs, but the section cited does not
sat you can't issue them. That is only a definition of a
wildcard cert.</div>
</div>
<br>
<br>
Rich Smith <a class="moz-txt-link-rfc2396E" href="mailto:richard.smith@comodo.com"><richard.smith@comodo.com></a> wrote:<br>
<br>
<div>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 moz-do-not-send="true"
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 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>_______________________________________________
Public mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
<br>
</body>
</html>