[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