[cabfpub] Proposed new ballot on IP Addresses in SANs

Rich Smith richard.smith at comodo.com
Thu Apr 21 17:33:14 UTC 2016


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
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160421/64eaa985/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/64eaa985/attachment-0001.p7s>


More information about the Public mailing list