<div dir="ltr">Rick, on a mozilla.dev.security.policy thread earlier today, you said (emphasis mine):<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>...I merely pointed out that <b>the BRs, as written, prohibit a type of wildcard </b>that Microsoft officially allows in TLS certificates (<a href="https://support.microsoft.com/en-us/kb/258858" target="_blank">https://support.microsoft.com/en-us/kb/258858</a>), specifically, w*.<a href="http://example.com" target="_blank">example.com</a> and <b>ww*.<a href="http://example.com" target="_blank">example.com</a></b><br></div><div><br></div></blockquote>That's from: <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/5ykbYX29U4A/Uf_NApirBgAJ" target="_blank">https://groups.google.com/d/msg/mozilla.dev.security.policy/5ykbYX29U4A/Uf_NApirBgAJ</a></div><div><br></div><div>You were referring to a discussion from March 16th on the CA/B Forum, in which you asked Microsoft for clarification: <a href="https://cabforum.org/pipermail/public/2016-March/006940.html" target="_blank">https://cabforum.org/pipermail/public/2016-March/006940.html</a></div><div><br></div><div>It sounds like you had agreed with everyone's initial early interpretation that allowing wildcards other than a leftmost "*" was non-compliant with the BRs. It doesn't seem like you believed that there was ambiguity until Jeremy suggested another way of looking at the BR language today.</div><div><br></div><div>I also don't think that this interpretation of the BRs is on solid ground. The BRs say:</div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>Wildcard Certificate: A Certificate containing an asterisk (*) in the left</div><div>‐most position of any of the Subject Fully‐Qualified Domain Names</div><div>contained in the Certificate.</div></div></blockquote></div><div><br></div><div>That to me unambiguously indicates *.<a href="http://example.com" target="_blank">example.com</a>, and not ww*.<a href="http://example.com" target="_blank">example.com</a>, regardless of whether "left-most position" is technically defined. Even if you could argue ambiguity by the absolute letter of the text, the spirit of the text seems very clear and it doesn't seem like there'd been debate or disagreement about this until very recently.</div><div><br></div><div>In the March email thread that Stephen Davidson opened about wildcards (<a href="https://cabforum.org/pipermail/public/2016-March/006933.html" target="_blank">https://cabforum.org/pipermail/public/2016-March/006933.html</a>), he noted some confusion about this, but he only noted confusion among *customers*, not among browsers or CAs:</div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>The browsers implement this to mean “the asterisk must ONLY be in the left‐most position and must constitute the ENTIRE label”.</div><div> </div><div>That being said, there is some confusion among SSL buyers about what is allowable.</div></div></blockquote></div><div><br></div><div>Reading the replies on that thread (<a href="https://cabforum.org/pipermail/public/2016-March/thread.html#6933" target="_blank">https://cabforum.org/pipermail/public/2016-March/thread.html#6933</a>), it looks very clear that the CA and browser community were all in collective agreement that they understood the BRs to intend to not allow ww*.<a href="http://example.com" target="_blank">example.com</a>, even if they had some difference of opinion about whether or how to change the text.</div><div><br></div><div>I think you would be better off arguing that a ballot is necessary to reconcile the BRs with existing CA business practices that have followed Microsoft requirements that were in contravention of the BRs, as it is not very persuasive to argue that the BRs have already permitted this and that there was never any misissuance at all.<br></div><div><br></div><div>However, given the discussion on the IP address proposal, which is very similar to this in concept, it doesn't look like there's a lot of sympathy for any particular company going outside the BRs to satisfy customer demand and then bringing that to the Forum as a legacy issue to accommodate.</div><div><br></div><div>-- Eric</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 4:31 PM, Rick Andrews <span dir="ltr"><<a href="mailto:Rick_Andrews@symantec.com" target="_blank">Rick_Andrews@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Starting with the last exchange between Rich and Jeremy from the other<br>
thread:<br>
<br>
[Rich] In the SAN section of the BRs it simply says, "Wildcard FQDNs are<br>
permitted."  To know WHAT is permitted you MUST look to the definition, and<br>
the definition clearly states "...left most position..."  Clearly these<br>
certificates are non-compliant.  And I don't buy for second that that's not<br>
understood by anyone who has participated in Forum discussions for any<br>
length of time.<br>
[JR] Wildcard FQDNs are not defined. Wildcard certs are.  Although I do<br>
think wildcards characters should be limited to the left most label, what is<br>
understood is largely irrelevant. The language matters and what the BRs say<br>
is definitely ambiguous and unclear.<br>
<br>
[Rich] And have we devolved to the point that we're now creating and editing<br>
requirements only to then go forth and have a competition to see which CA<br>
can out-do the others in finding loopholes in them?  Is that what this Forum<br>
has become?  If so, then what are we doing here?  Let's shutter the place<br>
and walk away.<br>
[JR] Pretty sure that’s the nature of any industry standards body. Plus, I<br>
think its incorrect to assume that anyone with a different interpretation of<br>
a section is willfully looking for loopholes. Precise language in any<br>
standard is important, especially when you consider that non-native English<br>
speakers are reviewing the document. In any event, if everyone agreed with<br>
interpretation, amending guidelines for language clarity should be a simple<br>
task.  Clearly Symantec interpreted the requirement differently than Comodo<br>
or DigiCert. However, given the language, I can’t agree that the certs are<br>
being mis-issued.<br>
<br>
[Rich] The IP address certs that started this discussion aren't even a<br>
loophole.  They are specifically and clearly non-compliant.  Now I'm not a<br>
lawyer, but I do view the action of issuing them as anti-competitive.  I've<br>
had specific cases wherein I couldn't issue EV certificates to labor unions<br>
in the U.S. for YEARS because the wording in the EV Guidelines at the time<br>
did not allow for them.  I came here, I advised the Forum of my plight, and<br>
asked for a solution.  No one disagreed that they clearly legally existed as<br>
an organization, but the solution was caught up in haggling over minutiae<br>
for YEARS before a suitable change to the Guidelines was officially adopted.<br>
I didn't just go ahead and issue the certificates anyway, I waited for the<br>
Forum to arrive at a consensus and fix the problem.  And as a participant in<br>
good faith here, that's what I expect of other participants.<br>
[JR] Which is why I’m petitioning to modify the requirements now. We have a<br>
definite use case where they are required by a major browser.  I’d like to<br>
see that accommodated. What happens with the certs issued prior to changing<br>
the requirements, as always, is up to the browsers. The CAB Forum has never<br>
had an enforcement mechanism. Without the browsers adoption, the guidelines<br>
are merely advisory. The EV processing document for example.<br>
<br>
------------------<br>
<br>
The BRs define Wildcard Certificate:<br>
"Wildcard Certificate: A Certificate containing an asterisk (*) in the left<br>
‐most position of any of the Subject Fully‐Qualified Domain Names<br>
contained in the Certificate."<br>
<br>
and then uses that definition in 3.2.2.6 Wildcard Domain Validation:<br>
"A CA is not prohibited from issuing a Wildcard Certificate to the<br>
Registrant of an entire gTLD, provided that control of the entire namespace<br>
is demonstrated in an appropriate way."<br>
<br>
and in 4.9.1.1.  Reasons for Revoking a Subscriber Certificate:<br>
"The CA SHALL revoke a Certificate... if the CA is made aware that a<br>
Wildcard Certificate has been used to authenticate a fraudulently misleading<br>
subordinate Fully-Qualified Domain Name;"<br>
<br>
Is "left-most position" technically defined? Does that mean the left-most<br>
character or left-most label? A name like "ww*.<a href="http://example.com" rel="noreferrer" target="_blank">example.com</a>" has an asterisk<br>
in the left-most label. So if position=label, that name is permitted.<br>
<br>
The only other place wildcards are mentioned are in the rest of 3.2.2.6<br>
Wildcard Domain Validation:<br>
"Before issuing a certificate with a wildcard character (*) in a CN or<br>
subjectAltName of type DNS‐ID, the CA MUST establish and follow a<br>
documented procedure that determines if the wildcard character occurs in the<br>
first label position to the left of a “registry‐controlled” label or<br>
“public suffix” (e.g. “*.com”, “*.<a href="http://co.uk" rel="noreferrer" target="_blank">co.uk</a>”, see RFC 6454 Section 8.2 for<br>
further explanation)."<br>
<br>
That sentence says that if the wildcard character appears in the first label<br>
position, the CA is required to check further. I would argue that in<br>
"ww*.<a href="http://example.com" rel="noreferrer" target="_blank">example.com</a>", the wildcard character appears in the first label. I<br>
think "first label position" is ambiguous and doesn't necessarily mean it is<br>
the entire label.<br>
<br>
The second paragraph in that section says:<br>
"If a wildcard would fall within the label immediately to the left of a<br>
registry‐controlled or public suffix, CAs MUST refuse issuance..."<br>
The word "within" indicates that the wildcard might not be the only<br>
character in the label.<br>
<br>
This is why we agree with Jeremy that the current language is ambiguous and<br>
doesn't clearly exclude wildcards like "ww*.<a href="http://example.com" rel="noreferrer" target="_blank">example.com</a>".<br>
<span><font color="#888888"><br>
-Rick<br>
</font></span><br>_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://konklone.com" target="_blank">konklone.com</a> | <a href="https://twitter.com/konklone" target="_blank">@konklone</a><br></div></div></div></div></div></div></div>
</div></div>