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

[Wayne Thayer]

On Mon, Oct 22, 2018 at 12:18 PM Ryan Sleevi <sleevi at google.com> wrote:

>
> On Fri, Oct 19, 2018 at 1:59 AM Wayne Thayer <wthayer at mozilla.com> wrote:
>
>> Here is a draft ballot that reflects my understanding of the outcome of
>> our discussion in Shanghai. I would appreciate your review of the language
>> for any logic gaps and for clarity. I'm also looking for two endorsers.
>>
>> - Wayne
>>
>> Ballot SC## - Sunset of Underscores in DNSNames
>>
>> Purpose of Ballot
>>
>> Ballot 202 included a provision creating a permanent exception permitting
>> the underscore character to be used in SAN fields of type DNSName. Since
>> that ballot failed in 2017, the practice has continued despite being
>> non-compliant with RFC 5280. This ballot creates a brief sunset period
>> intended to allow Subscribers who are relying on FQDNs containing
>> underscores to transition away from them, either by changing the name or
>> deploying a wildcard certificate.
>>
>> The following motion has been proposed by Wayne Thayer of Mozilla and
>> endorsed by xxx of yyy and xxx of yyy.
>>
>> --- MOTION BEGINS ---
>> Add the following language to BR section 7.1.4.2.1 (Subject Alternative
>> Name Extension):
>>
>> Prior to February 1, 2020, certificates containing underscore characters
>> in domain labels in DNSName entries MAY be issued as follows:
>> * DNSName entries MAY include underscore characters (“_”) in domain
>> labels such that replacing all underscore characters with hyphen characters
>> (“-“) would result in a valid domain label, and;
>> * After May 31, 2019, such certificates MUST NOT be valid for longer than
>> 45 days.
>>
>
> This doesn't seem to match the discussion in Shanghai, particularly around
> the dates.
>
> Yes, we discussed 30-day durations in Shanghai. I increased it to 45 days
based on feedback from CAs stating that the same enterprise subscribers who
will need time to migrate aware from labels containing underscores also
have bureaucratic change management processes. I don't have a lot of
sympathy for that argument and am happy to go with 30 days, but I also feel
that 45 day durations create enough pain to achieve the goal of pressuring
organizations to move off of these certificates prior to the 2020 deadline.

The suggestion here was an immediate migration to 30 day certificates
> (where "immediate" here can be read w/in 30 days of the ballots IP review),
> and a revocation period 6 months after (which would put it around April).
>
> That's not what I was thinking during the discussion. Again, my primary
goal is to make a clear statement of policy in the BRs. My secondary goal
is to provide subscribers who don't recognize this as a problem some time
to transition. I believe my proposal achieves the second goal better than
an immediate shift to 30-day validity periods.

The discussion in Shanghai similarly looked at whitelists as a further
> mitigation.
>
> Yes, and I rejected that as unnecessarily complex. I would be happy to put
in a requirement for CAs to warn subscribers that this practice is being
deprecated, but I really don't see brand new uses of labels containing
underscores as the problem. A whitelist also creates the impression that
there will be an exception process - something I feel strongly that we
should avoid.

It seems strongly anti-competitive, and against the security and stability
> of the ecosystem, to adopt with the timing suggested. Every CA who declined
> a customer's business on the basis of adhering to the requirements gets a
> slap across the face for prioritizing compliance and security - in that
> their competitors who repeatedly violated the BRs can potentially continue
> to issue. Further, such a ballot would *encourage* more CAs to begin
> permitting such certificates - precisely because it's now attractive and
> blessed. This does not seem a right way to help maintain an ecosystem, and
> would be disastrous to any other requirement - because it explicitly states
> that continued misissuance will be rewarded.
>
> Yes, there is some moral hazard in addressing this situation as I'm
proposing. However, I don't think that ignoring the real confusion that
exists and doing nothing more than continuing to argue for how wrong it is
will be very effective. If there is no BR amendment, I'm confident that
we'll see misissuance of underscores in DNSNames for years to come.

Further, there's the very real question that these should be qualifications
> on audits. There's no reason to believe they shouldn't have been
> qualifications before, but such an exception seems to have the goal of
> preventing such qualifications from appearing. This similarly seems to be a
> slap across the notion of the Baseline Requirements being requirements,
> since it would be granting retroactive acceptance.
>
> I really don't care if these are qualifications. Do you have a proposal
for how that could be accomplished?

Finally, it doesn't set an actual sunset date for migration, and that
> itself seems problematic. There's no reason or data to support the notion
> that 4000 certificates - whose mere existence threatens the
> interoperability of the ecosystem w/r/t TLS, the security of the ecosystem
> w/r/t URL parsing and resolution, and the reliability of the Baseline
> Requirements and the auditing profession - somehow justifies the need to
> continue supporting such certificates beyond October 2019, at the latest.
>

Sure it does - the last valid certificate under my proposal expires on
March 1, 2020.

Again, I am hoping to find a compromise that definitively ends this
problem. Unless you prefer the status quo, providing specific
recommendations that would make my proposal more acceptable would be more
helpful than continuing to point out all the reasons why you think it's bad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181023/73e09026/attachment-0001.html>