[cabfpub] Wildcard language in BRs
eric at konklone.com
Thu Apr 21 21:13:43 UTC 2016
Rick, on a mozilla.dev.security.policy thread earlier today, you said
...I merely pointed out that *the BRs, as written, prohibit a type of
wildcard *that Microsoft officially allows in TLS certificates (
https://support.microsoft.com/en-us/kb/258858), specifically, w*.example.com
and *ww*.example.com <http://example.com>*
You were referring to a discussion from March 16th on the CA/B Forum, in
which you asked Microsoft for clarification:
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.
I also don't think that this interpretation of the BRs is on solid ground.
The BRs say:
Wildcard Certificate: A Certificate containing an asterisk (*) in the left
‐most position of any of the Subject Fully‐Qualified Domain Names
contained in the Certificate.
That to me unambiguously indicates *.example.com, and not ww*.example.com,
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.
In the March email thread that Stephen Davidson opened about wildcards (
https://cabforum.org/pipermail/public/2016-March/006933.html), he noted
some confusion about this, but he only noted confusion among *customers*,
not among browsers or CAs:
The browsers implement this to mean “the asterisk must ONLY be in the
left‐most position and must constitute the ENTIRE label”.
That being said, there is some confusion among SSL buyers about what is
Reading the replies on that thread (
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*.
example.com, even if they had some difference of opinion about whether or
how to change the text.
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.
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.
On Thu, Apr 21, 2016 at 4:31 PM, Rick Andrews <Rick_Andrews at symantec.com>
> Starting with the last exchange between Rich and Jeremy from the other
> [Rich] 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
> understood is largely irrelevant. The language matters and what the BRs say
> is definitely ambiguous and unclear.
> [Rich] And have we devolved to the point that we're now creating and
> 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
> 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
> 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.
> [Rich] 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
> an organization, but the solution was caught up in haggling over minutiae
> for YEARS before a suitable change to the Guidelines was officially
> 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
> 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.
> The BRs define Wildcard Certificate:
> "Wildcard Certificate: A Certificate containing an asterisk (*) in the left
> ‐most position of any of the Subject Fully‐Qualified Domain Names
> contained in the Certificate."
> and then uses that definition in 220.127.116.11 Wildcard Domain Validation:
> "A CA is not prohibited from issuing a Wildcard Certificate to the
> Registrant of an entire gTLD, provided that control of the entire namespace
> is demonstrated in an appropriate way."
> and in 18.104.22.168. Reasons for Revoking a Subscriber Certificate:
> "The CA SHALL revoke a Certificate... if the CA is made aware that a
> Wildcard Certificate has been used to authenticate a fraudulently
> subordinate Fully-Qualified Domain Name;"
> Is "left-most position" technically defined? Does that mean the left-most
> character or left-most label? A name like "ww*.example.com" has an
> in the left-most label. So if position=label, that name is permitted.
> The only other place wildcards are mentioned are in the rest of 22.214.171.124
> Wildcard Domain Validation:
> "Before issuing a certificate with a wildcard character (*) in a CN or
> subjectAltName of type DNS‐ID, the CA MUST establish and follow a
> documented procedure that determines if the wildcard character occurs in
> first label position to the left of a “registry‐controlled” label or
> “public suffix” (e.g. “*.com”, “*.co.uk”, see RFC 6454 Section 8.2 for
> further explanation)."
> That sentence says that if the wildcard character appears in the first
> position, the CA is required to check further. I would argue that in
> "ww*.example.com", the wildcard character appears in the first label. I
> think "first label position" is ambiguous and doesn't necessarily mean it
> the entire label.
> The second paragraph in that section says:
> "If a wildcard would fall within the label immediately to the left of a
> registry‐controlled or public suffix, CAs MUST refuse issuance..."
> The word "within" indicates that the wildcard might not be the only
> character in the label.
> This is why we agree with Jeremy that the current language is ambiguous and
> doesn't clearly exclude wildcards like "ww*.example.com".
> Public mailing list
> Public at cabforum.org
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public