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

[Wayne Thayer]

Rich,

If you dislike the way in which I'm attempting to put this issue to rest,
please feel free to propose your own ballot. I will not be offended. I
will, however, not support another sunset that assumes subscribers will
know or care about the change until their existing certs are revoked, as is
the case with what you proposed below.

- Wayne

On Wed, Oct 24, 2018 at 12:38 PM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> 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/3e22552e/attachment.html>