[cabfpub] Proposed new ballot on IP Addresses in SANs

Rich Smith richard.smith at comodo.com
Thu Apr 21 22:41:21 UTC 2016

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:*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 <richard.smith at comodo.com>
> *Cc:* 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 <richard.smith at comodo.com 
> <mailto:richard.smith at comodo.com>> wrote:
> 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:
> lab-rct-*.us.kworld.kpmg.com
> lab-rct-*.us.kpmg.com
> rct-*.us.kpmg.com
> 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.
> Regards,
> Rich Smith
> Validation Manager
> Comodo
> On 4/21/2016 8:23 AM, Ryan Sleevi wrote:
>     On Thu, Apr 21, 2016 at 6:13 AM, Jody Cloutier
>     <jodycl at microsoft.com <mailto: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.
>     Jody,
>     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.
>     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
>     Public at cabforum.org  <mailto:Public at cabforum.org>
>     https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160421/a25f7c07/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4035 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160421/a25f7c07/attachment-0001.p7s>

More information about the Public mailing list