[cabfpub] Proposed new ballot on IP Addresses in SANs

Jeremy Rowley jeremy.rowley at digicert.com
Thu Apr 21 23:03:25 UTC 2016

Two arguments:

1)      It’s in the left-most label. If you read left most position as
“label”, the language doesn’t require it to be the only character in the
left-most label. Therefore, this is a Wildcard Cert in that the wildcard
character is in the left-most label of the cert even if it’s not the only
character. Totally legit reading considering neither label nor position is

2)      It’s not a wildcard cert because it doesn’t have a character in
the leftmost position of the cert. Therefore, it’s not covered by the BR
requirements of 3.2.26

“Before issuing a certificate with a wildcard character (*) in a CN or
subjectAltName of type DNS‐ID, the CA MUST establish and follow a
documented procedure† that determines if the wildcard character occurs in
the first label position to the left of a “registry‐controlled” label or
“public suffix” (e.g. “*.com”, “*.co.uk”, see RFC 6454 Section 8.2 for
further explanation).”

Based on this, I’m not seeing where it requires them to only include the
wildcard character as the only character.  I am happy to endorse a ballot to
correct this though.

On the other hand the “*.*.example.com” certs are much more difficult to

From: Rich Smith [mailto:richard.smith at comodo.com]
Sent: Thursday, April 21, 2016 4:41 PM
To: Stephen Davidson
Cc: Jeremy Rowley; public at cabforum.org
Subject: Re: [cabfpub] Proposed new ballot on IP Addresses in SANs

Wait, what?  How is it arguable that the wildcard is in the left most
position in this: lab-rct-*.us.kworld.kpmg.com?
Or any of the other certificates indicated in my original email on this?

On 4/21/2016 4:38 PM, Stephen Davidson wrote:

And it is arguable that the wildcard is in fact “in the left-most
position” … Hence the ballot clarifying that the sole wildcard must
constitute the entirety of the left-most label.

From:  <mailto:public-bounces at cabforum.org> public-bounces at cabforum.org [
<mailto:public-bounces at cabforum.org> mailto:public-bounces at cabforum.org] On
Behalf Of Jeremy Rowley
Sent: Thursday, April 21, 2016 2:55 PM
To: Rich Smith  <mailto:richard.smith at comodo.com> <richard.smith at comodo.com>
Cc:  <mailto:public at cabforum.org> public at cabforum.org
Subject: Re: [cabfpub] Proposed new ballot on IP Addresses in SANs

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.

Rich Smith < <mailto:richard.smith at comodo.com> richard.smith at comodo.com>

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.

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:


See:  <https://crt.sh/?cablint=65&iCAID=1449&opt=cablint>

The BRs state, in definitions section:

Wildcard Certificate: A Certificate containing an asterisk (*) in the
left-most position [emphasis mine] of any of the Subject Fully-Qualified
Domain Names contained in the Certificate.

Rich Smith
Validation Manager

On 4/21/2016 8:23 AM, Ryan Sleevi wrote:

On Thu, Apr 21, 2016 at 6:13 AM, Jody Cloutier <
<mailto:jodycl at microsoft.com> jodycl at microsoft.com> wrote:

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.


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

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.

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.

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.

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.

Public mailing list
 <mailto:Public at cabforum.org> Public at cabforum.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160421/56c94d8e/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160421/56c94d8e/attachment-0001.p7s>

More information about the Public mailing list