[Servercert-wg] [cabf_validation] Underscores, DNSNames, and SRVNames

[Wayne Thayer]

On Wed, Oct 24, 2018 at 1:08 PM Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Underscores were prohibited before ballot 202 and they remain prohibited
> after the ballot, no change.  Let’s proceed with pushing this to closure
> with a short effective date.
>
>
>
+1

It pains me to say J I agree with Ryan’s earlier question asking where this
> belongs (BRs or Mozilla policy).  If the BRs currently prohibit the use of
> underscores in DNSNames, and we want to re-iterate this (while we have a
> grace period), why do we want to update the BRs only to revert them back
> again?
>

One of my goals is to leave a big signpost telling CAs not to do this in
the future, so this is not a temporary BR change.

A root program requirement also will not be ingested by the auditors, and
part of the problem here is that they are continuing to ignore this issue
(probably because they don't feel that they have clear guidance from the
Forum).

Isn’t a root program requirement sufficient to permit a disclosed and
> monitored period of transition for the affected customers and CAs while
> issuance of certificates with underscores remains a misissuance event for
> everyone?
>
>
>
I don't really see how a single root program's requirement creates an
unambiguous path to ending this practice. Mozilla saying "go ahead and
misissue for a while" leaves CAs with conflicting requirements and - I
would bet - will result in some stopping and others continuing to issue
these certs then using Mozilla's policy as an excuse.

That is not to say that I'm not thinking about doing something
unilaterally. That would most likely be technical enforcement of the rule
(as I suggested to Ryan), perhaps coupled with a clear statement in Mozilla
policy that it is forbidden. However, I believe that we all benefit when
problems like this are solved collaboratively, and in any case this
conversation is about what to do (or not do) in the CAB Forum.

I’d recommend Wayne make an “immediate” update to the Mozilla root program
> with the rules and schedule he’s provided.  If there are certain whitelists
> that need to be created due to special circumstances, that could be granted
> and disclosed in Bugzilla on a case by case basis.  This permits Mozilla to
> both specify and enforce this temporary solution without opening up
> issuance to all CAs, and we can do that a lot faster than BR ballots.
> Didn’t we do with SHA-1 issuances past the BR sunset date?  If you need to
> knowingly break the BRs going forward, at least get a blessing from a root
> program.  It’s not even clear if Wayne’s ballot would pass.
>
>
>
I think this is a misunderstanding of how Mozilla operates. I wouldn't make
a change like this without a public discussion, or in the case of a
technical control, an impact analysis.

I'm not keen on treating this like an exception process because I feel that
it invites organizations to keep asking for more exceptions. Whatever we do
I'd like to set a clear date after which the practice will no longer be
tolerated - no exceptions.

Doug
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Tim
> Hollebeek via Servercert-wg
> *Sent:* Wednesday, October 24, 2018 3:39 PM
> *To:* Richard Smith <rich at comodoca.com>; CA/B Forum Server Certificate WG
> Public Discussion List <servercert-wg at cabforum.org>; Wayne Thayer <
> wthayer at mozilla.com>; Ryan Sleevi <sleevi at google.com>
> *Subject:* Re: [Servercert-wg] [cabf_validation] Underscores, DNSNames,
> and SRVNames
>
>
>
> Failed ballots do not change the requirements.  The position that the
> failure of a ballot imposes some new requirement on members is not
> supportable.
>
>
>
> -Tim
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Richard
> Smith via Servercert-wg
> *Sent:* Wednesday, October 24, 2018 3:27 PM
> *To:* Wayne Thayer <wthayer at mozilla.com>; Ryan Sleevi <sleevi at google.com>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] [cabf_validation] Underscores, DNSNames,
> and SRVNames
>
>
>
> As has been stated, after the failure of Ballot 202 IMO no CA which was a
> member of this Forum at that time has a reasonable defense to have
> continued issuing such certificates.  If there are CAs which are NOT
> members of this Forum MAYBE they have a leg to stand on.
>
>
>
> At this point the only defensible ballot IMO is one which clearly states
> that issuing certificates with underscores in the DNSname is not allowed,
> and takes immediate effect upon passage.  The one allowance I would make
> for subscriber pain is to allow 180 days before revocation of the existing
> ones, but I do not support allowing any additional issuance even for those
> which are due to expire in a shorter timeframe.
>
>
>
> Regards,
>
> Rich
>
>
>
> *From:* Wayne Thayer <wthayer at mozilla.com>
> *Sent:* Wednesday, October 24, 2018 10:55 AM
> *To:* Ryan Sleevi <sleevi at google.com>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>; Richard Smith <rich at comodoca.com>
> *Subject:* Re: [Servercert-wg] [cabf_validation] Underscores, DNSNames,
> and SRVNames
>
>
>
> On Tue, Oct 23, 2018 at 10:39 PM Ryan Sleevi <sleevi at google.com> wrote:
>
>
>
> On Wed, Oct 24, 2018 at 12:07 AM Wayne Thayer <wthayer at mozilla.com> wrote:
>
> In not responding to my questions about the whitelist, are you accepting
> my position or just pocketing that to use as a point of contention later on?
>
>
>
> It was unclear if those were purely rhetorical, especially since there's a
> more pertinent question that I posed which is necessary to answer - which
> is to understand why Mozilla itself is not maintaining this "ignore the
> RFCs" process, if it believes violating RFC 5280 is acceptable.
> Understanding the dependencies - for example, whether you expect to discuss
> this on Mozilla dev-security-policy with the community before adopting a
> position and where/how this differs from how Mozilla has treated other
> violations of RFC 5280, especially around domain names (for example,
> umlauts or double-dots) helps answer the question of where and how a
> whitelist can or should be constructed or maintained.
>
>
>
> A suggestion for the construction of this had been given at Shanghai,
> which was to examine the set of publicly disclosed certificates at "Date
> X", that cannot migrate to wildcards, as the basis for a whitelist. This
> seems to align with Mozilla process of requiring public disclosure of
> misissuance, scope, and handling. Since that discussion in Shanghai, the
> data available has shown that it's 166 domains. If CAs believe it to be a
> greater problem, I would have thought they'd shared data by now - much as
> they do when they misissue certificates - by logging to CT logs.
>
>
>
> Concrete numbers would look at March 1 -> Dec 1, 2018 and October 1, 2019
> -> April 1, 2019.
>
>
>
> In your previous message you said the suggestion was 3 months for complete
> revocation of existing certificates. Starting from the time this ballot can
> be ratified, I get to roughly March 1st. And you said complete sunset <=1y,
> which I again thought I had adopted. How do you square these proposed dates
> with your prior statements?
>
>
>
> You mean
> https://cabforum.org/pipermail/servercert-wg/2018-October/000317.html and
> captured in
> https://cabforum.org/pipermail/servercert-wg/2018-October/000331.html ?
> Because the continued analysis of the numbers, and the lack of
> counter-criteria in response to
> https://cabforum.org/pipermail/servercert-wg/2018-October/000331.html
>
>
>
> Then am I right to believe that you would now support the following ballot
> language?
>
> ==================
>
>
>
> Prior to April 1, 2019, certificates containing underscore characters
> (“_”) in domain labels in DNSName entries MAY be issued as follows:
>
> * DNSName entries MAY include underscore characters in the left most
> domain label such that replacing all underscore characters with hyphen
> characters (“-“) would result in a valid domain label, and;
>
> * Such certificates MUST NOT be valid for longer than 30 days.
>
> All certificates containing an underscore character in any DNSName entry
> and having a validity period of more than 30 days MUST be revoked prior to
> December 1, 2018.
>
>
>
> After April 30, 2019, underscore characters (“_”) MUST NOT be present in
> DNSName entries.
>
>
>
> ==================
>
> If we compare to other forms of invalid domains - all of which Mozilla has
> required incident reports and treated as misissuance (e.g. invalid
> characters in the domain, double-dots, internal server names, names with
> spaces, names with UTF-8 characters), it's 872 domains across 1108
> unexpired certificates. The ecosystem did not melt down when those were
> revoked, what makes this special and unique? If I were a CA wanting to make
> the same argument that CAs (and seemingly, browsers, are making), then the
> inclusion of spaces, symbols like @, and double dots, are all controlled by
> the same section controlling underscores, and like underscores, we have
> other systems allowing all of them (see
> https://tools.ietf.org/html/rfc6763#section-4.1.1 for a specific rule -
> DNS-SD TXT records - with
> https://tools.ietf.org/html/rfc6763#section-4.1.3 showing specific
> examples). Why can't I point to that and say that it was "confusing" that
> the BRs prohibited certificates for those records? I can resolve them with
> resolver APIs (since they support TXT), does that make them "correct" for
> certificates?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181024/6bb88080/attachment-0001.html>