[cabfpub] Proposed new ballot on IP Addresses in SANs

Thu Apr 21 12:58:58 MST 2016

I would strongly recommend separating the wildcard discussion into a
separate thread, if it's a BR ambiguity or potential misissuance that
deserves separate remediation.

That would help this thread stay on target as a discussion of whether or
not Symantec's proposed change is reasonable, rather than a debate about
Symantec as a company.

-- Eric

On Thu, Apr 21, 2016 at 3:48 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

>
>
> 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.
> [JR] Wildcard FQDNs are not defined. Wildcard certs are.  Although I do
> think wildcards characters should be limited to the left most label, what
> is understood is largely irrelevant. The langue matters and what the BRs
> say is definitely ambiguous and unclear.
>
> 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.
> [JR] Pretty sure that’s the nature of any industry standards body. Plus, I
> think its incorrect to assume that anyone with a different interpretation
> of a section is willfully looking for loopholes. Precise language in any
> standard is important, especially when you consider that non-native English
> speakers are reviewing the document. In any event, if everyone agreed with
> interpretation, amending guidelines for language clarity should be a simple
> task.  Clearly Symantec interpreted the requirement differently than Comodo
> or DigiCert. However, given the language, I can’t agree that the certs are
> being mis-issued.
>
> 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.
>
> [JR] Which is why I’m petitioning to modify the requirements now. We have
> a definite use case where they are required by a major browser.  I’d like
> to see that accommodated. What happens with the certs issued prior to
> changing the requirements, as always, is up to the browsers. The CAB Forum
> has never had an enforcement mechanism. Without the browsers adoption, the
> guidelines are merely advisory. The EV processing document for example.
>
>
>
> On 4/21/2016 12:54 PM, Jeremy Rowley wrote:
>
> 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> <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>
> 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
>
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>

-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160421/07664b85/attachment.html 