[cabfpub] Wildcard language in BRs

[Rick Andrews]

Starting with the last exchange between Rich and Jeremy from the other
thread:

[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 is
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 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.

[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 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.

------------------

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 3.2.2.6 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 4.9.1.1.  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 misleading
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 asterisk
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 3.2.2.6
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 the
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 label
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 is
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".

-Rick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5749 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20160421/28cc31bd/attachment-0001.bin