CA Communication: Underscores in dNSNames

[Wayne Thayer]

As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
creating a sunset period for TLS certificates containing an underscore
("_") character in the SAN. This practice was widespread until a year ago
when it was pointed out that underscore characters are not permitted in
dNSName name forms, and ballot 202 was proposed to create an exception to
RFC 5280 that would allow the practice to continue. When that ballot
failed, some CAs stopped allowing underscore characters in SANs and others
continued. Ballot SC12 is intended to resolve this inconsistency and
provide clear guidance to auditors.

The sunset period defined by ballot SC12 is very short. Today Mozilla sent
an email to all CAs in our program informing them of this change and asking
them to take any steps necessary to comply [2].

- Wayne

[1]
https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
[2]
https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29

[Man Ho]

When the ballot said "... would result in a valid domain label", does it
mean that "... would result in a valid domain name of the applicant,
that has passed the same level of domain authorization (DV, OV, EV) check?

Secondly, is it necessary for CAs to state their practice of handling
underscore domain name in CPS?

- Man Ho

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Wayne Thayer]

On Mon, Nov 12, 2018 at 6:18 PM Man Ho via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> When the ballot said "... would result in a valid domain label", does it
> mean that "... would result in a valid domain name of the applicant,
> that has passed the same level of domain authorization (DV, OV, EV) check?
>

> No, this does not mean that the CA needs to perform domain validation on
the FQDN with underscores replaced by hyphens. It means that underscores
are only permitted in certain positions within the domain label, as
discussed in the lead-up to ballot 202 (this language is copied directly
from ballot 202). For example:
https://cabforum.org/pipermail/public/2017-May/011186.html

Secondly, is it necessary for CAs to state their practice of handling
> underscore domain name in CPS?
>

> No, that is not a Mozilla requirement.

[Wayne Thayer]

It was pointed out that the email I sent to CAs stated that the effective
date of the ballot (once it completed the IPR review period) will be
December 10, **2019**. The year is obviously wrong and contradicts the rest
of the message. The correct effective date is December 10, **2018**. All of
the relevant compliance dates in the email are correct, so I'm not planning
to resend the CA communication.

- Wayne

[Vincent Lynch]

Was looking for some quick clarification on interpretation of this bit:

*"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
January 15, 2019."*

This language refers to the TOTAL validity period of the certificate, not
the REMAINING validity, correct?

So, for example, a certificate with a NotBefore: 2/1/18 and NotAfter:
1/30/19 would have to be revoked?
Only certificate swith a TOTAL validity of <30 days (example, NotBefore:
12/20/18, NotAfter: 1/19/19) would be allowed to naturally expire?

Thanks,

Vincent

On Mon, Nov 12, 2018 at 4:19 PM Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
> creating a sunset period for TLS certificates containing an underscore
> ("_") character in the SAN. This practice was widespread until a year ago
> when it was pointed out that underscore characters are not permitted in
> dNSName name forms, and ballot 202 was proposed to create an exception to
> RFC 5280 that would allow the practice to continue. When that ballot
> failed, some CAs stopped allowing underscore characters in SANs and others
> continued. Ballot SC12 is intended to resolve this inconsistency and
> provide clear guidance to auditors.
>
> The sunset period defined by ballot SC12 is very short. Today Mozilla sent
> an email to all CAs in our program informing them of this change and asking
> them to take any steps necessary to comply [2].
>
> - Wayne
>
> [1]
>
> https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
> [2]
>
> https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Vincent Lynch

[Wayne Thayer]

On Wed, Nov 14, 2018 at 9:47 AM Vincent Lynch <vtl...@gmail.com> wrote:

> Was looking for some quick clarification on interpretation of this bit:
>
> *"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
> January 15, 2019."*
>
> This language refers to the TOTAL validity period of the certificate, not
> the REMAINING validity, correct?
>

> Correct.

So, for example, a certificate with a NotBefore: 2/1/18 and NotAfter:
> 1/30/19 would have to be revoked?
>

Yes.

Only certificates with a TOTAL validity of <30 days (example, NotBefore:

> 12/20/18, NotAfter: 1/19/19) would be allowed to naturally expire?
>

> Yes. The thinking here is that many organizations don't pay attention to
certificate sunsets (e.g. sha-1) until it affects them directly. By
requiring them to replace their certificates while still allowing some time
to transition away from them via 30-day duration certificates, the hope is
that we will avoid the urgent calls for exceptions we've seen with past
sunset periods.

[Bruce]

Hi Wayne, I wanted to get some clarification.

For example, let's say that a Subscriber has a 1 year certificate which expires on 30 January 2019. On 15 January 2019, the remaining validity period is less than 30 days; as such, I interpret that the certificate does not have to be revoked.

On the other hand, if the Subscriber has a 1 year certificate which expires on 31 March 2019, then on 15 January 2019, the remaining validity period is greater than 30 days, so this certificate must be revoked.

Is the above interpretation correct?

Thanks, Bruce.

[Tim Shirley]

Validity period is a defined term in the BRs and refers to the time between issuance and expiry. Since the new language uses that term without any modifiers like "remaining", it seems clear to me that both of those example certificates would need to be revoked.
________________________________
From: dev-security-policy <dev-security-...@lists.mozilla.org> on behalf of Bruce via dev-security-policy <dev-secur...@lists.mozilla.org>
Sent: Wednesday, November 14, 2018 5:37:20 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: CA Communication: Underscores in dNSNames

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org

https://scanmail.trustwave.com/?c=4062&d=qqPs2ylE2M0AE1hucuCDnbrKTL8yhgbe2AJ51iwegw&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy

[Wayne Thayer]

I agree with Tim on the interpretation and can confirm that my intent was
as Tim described.

Perhaps the confusion is over the purpose of the <30 day exception. It
wasn't to exempt legacy certificates near the end of their lifetime from
being revoked. It was to allow subscribers to begin using 30-day duration
certificates prior to 15-January without having to replace them on the 15th.

On Wed, Nov 14, 2018 at 4:20 PM Tim Shirley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Validity period is a defined term in the BRs and refers to the time
> between issuance and expiry. Since the new language uses that term without
> any modifiers like "remaining", it seems clear to me that both of those
> example certificates would need to be revoked.
> ________________________________
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
> on behalf of Bruce via dev-security-policy <
> dev-secur...@lists.mozilla.org>
> Sent: Wednesday, November 14, 2018 5:37:20 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: CA Communication: Underscores in dNSNames
>
> Hi Wayne, I wanted to get some clarification.
>
> For example, let's say that a Subscriber has a 1 year certificate which
> expires on 30 January 2019. On 15 January 2019, the remaining validity
> period is less than 30 days; as such, I interpret that the certificate does
> not have to be revoked.
>
> On the other hand, if the Subscriber has a 1 year certificate which
> expires on 31 March 2019, then on 15 January 2019, the remaining validity
> period is greater than 30 days, so this certificate must be revoked.
>
> Is the above interpretation correct?
>
> Thanks, Bruce.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
>

> https://scanmail.trustwave.com/?c=4062&d=qqPs2ylE2M0AE1hucuCDnbrKTL8yhgbe2AJ51iwegw&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy

[Rob Stradling]

Wayne, many thanks for drawing the attention of the CAs to this matter.

Sectigo (formerly Comodo CA) stopped issuing certificates with
underscores in dNSNames soon after CABForum ballot 202 failed. A search
of our CA database this week found 251 certificates that are in scope
for the BRs, expire on or after 15th January 2019, and that have at
least one underscore in a dNSName.

To track Sectigo's progress towards the 15th January 2019 revocation
deadline, I've created a new batch on Alex Gaynor's excellent Revocation
Tracker:

https://misissued.com/batch/41/

On 12/11/2018 23:18, Wayne Thayer via dev-security-policy wrote:
> As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
> creating a sunset period for TLS certificates containing an underscore
> ("_") character in the SAN. This practice was widespread until a year ago
> when it was pointed out that underscore characters are not permitted in
> dNSName name forms, and ballot 202 was proposed to create an exception to
> RFC 5280 that would allow the practice to continue. When that ballot
> failed, some CAs stopped allowing underscore characters in SANs and others
> continued. Ballot SC12 is intended to resolve this inconsistency and
> provide clear guidance to auditors.
>
> The sunset period defined by ballot SC12 is very short. Today Mozilla sent
> an email to all CAs in our program informing them of this change and asking
> them to take any steps necessary to comply [2].
>
> - Wayne
>
> [1]
> https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
> [2]
> https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

[pilgr...@gmail.com]

I need some clarification on something here

1) Why are legacy certs not being allowed to expire, and instead we are being forced to replace in a very short window? We stopped issuing certs with underscores as soon as our CA told us to (probably mid-September) but that still puts me at having hundreds of certs needing remediation in a period where retail production systems are not allowed to be touched.

2) If a certificate is not used to host a URL (say for server to server communication or 2way SSL... what does it matter, and can we allow those to remain till natural expiration?

3) Is there any exception process available that will allow us to keep our existing certs through their validity?

Thank you

[Wayne Thayer]

On Thu, Dec 6, 2018 at 10:36 PM pilgrim2223--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I need some clarification on something here
>
> 1) Why are legacy certs not being allowed to expire, and instead we are
> being forced to replace in a very short window? We stopped issuing certs
> with underscores as soon as our CA told us to (probably mid-September) but
> that still puts me at having hundreds of certs needing remediation in a
> period where retail production systems are not allowed to be touched.
>

> Experience with past sunsets (e.g. sha-1) has proven that allowing
certificates to naturally expire results in a bad outcome - Subscribers are
somehow unaware of the sunset until their certificate is about to expire,
at which point they can't get a replacement certificate and don't have time
to fix their systems. The revocation requirement ensures that Subscribers
are aware of the sunset while the provision for continued issuance of
30-day duration certificates provides additional time to update systems.
The short window is the result of a compromise with certain CAs and
browsers that argued for no sunset period at all because underscores have
never been permitted in BR-compliant certificates. That conclusion would
in-turn trigger the 5-day revocation requirement from section 4.9.1.1 of
the BRs.

2) If a certificate is not used to host a URL (say for server to server
> communication or 2way SSL... what does it matter, and can we allow those to
> remain till natural expiration?
>

> This sounds like a case where a publicly-trusted TLS server certificate is
being used for something other than the intended purpose. Unfortunately,
doing that carries the risk that those certificates will need to adapt to
[sometime rapid] changes to the requirements for TLS server certificates.
This also happened with the sha-1 sunset and is a good example of why it's
not a good idea to use publicly-trusted TLS server certificates for other
purposes.

3) Is there any exception process available that will allow us to keep our
> existing certs through their validity?
>

> There is no process for granting an exception to the BRs without the
consequence of a potential audit finding for the CA. It's up to the CA to
determine if they want to take the risk of an audit finding. It would
likely help to quantify the problem in terms of how many certificates, how
much extra time would be required to replace them, what steps are being
taken to expedite replacement, and what the risk/consequences are of having
these certificates revoked prior to replacement.

Thank you
>
> On Monday, November 12, 2018 at 4:19:17 PM UTC-7, Wayne Thayer wrote:

[pilgr...@gmail.com]

Thank you very much for your response!

So at the end of the day I will not get any relief from the browsers, and will need to get an exception from my CA?

When I asked the CA they told me to take it here. Feels like the CA is where I'm going to have to focus!

Thanks again for your time!

[Jeremy Rowley]

Personally, i think you should continue the discussion here. Although you can bring it up to whichever ca you use, the reality is that without the browsers knowing why the certs cant be replaced and the number, theres no way to gauge their reaction to a non compliance. The penalties may include root removal (see symantec) so I doubt many cas would be willing to risk a qualification without clear guidance from the browsers on the risk associated with the non compliance.
________________________________
From: dev-security-policy <dev-security-...@lists.mozilla.org> on behalf of pilgrim2223--- via dev-security-policy <dev-secur...@lists.mozilla.org>
Sent: Friday, December 7, 2018 8:26:42 AM

To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: CA Communication: Underscores in dNSNames

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org

https://clicktime.symantec.com/a/1/nN3YNjTD37Z9bk8efCYXsWHpyw8ViK61Q8Dz1AzUtno=?d=cQ4KQMo02NQvJ7GQxkZHfn9YbOkOTiGLFwgAhzovU-ksifF97AFzeTEl3fKU1c4flMJM5MQa4SYfNOuCB5-Y29jyEtL2_9KBxlVmHB_-8X_yPT3Gd1KBASJgcwXjKaIjjc7h8rFYLmo4FmmjdQDJfQcxl_q00tAfBZTdTqkwLD4b__i1PLIwekimsAKnCEc7M1LQPr1uSNB-FjHnEcF14WbG_18ILSXzHM34tK_cdKnINlfFOEvMSGXK7LVBeRjiRGTuodckiUppT5eIbtRZNKo6R8hoXcUzy-yTZ21EbW651pPGEqEwRb1Qpu9J0tLL6DExVNq6euprfMtWQTwjpQGvzkg5KO26pXSnafFpMBxblo_G0EcAZEMPzGWZrQxxtD8_wSHTTO7-9MbzrQGF8qAWuuFbGW-M220s2HRhgU8qz_qZtto%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[Jeremy Rowley]

This isn't a CA-issue because the risk associated with non-compliance isn't
defined yet. From what I've heard here, the risk is distrust or loss of EV
indicators, which is distrust-like. That's a pretty big thing to push back
on the CA for a non-security issue. Thus, I think the risk of missing the
underscore revocation date needs to be discussed here so everyone, including
website operators and the relying parties, know first-hand what the risks of
the CA missing the deadline are. If the risk is that there is a note on the
audit, that is an acceptable risk. If the risk is a loss of the
root...probably less so. Pushing the question back to the CA without better
discussion by the browsers makes finding a solution or understanding the
risks impossible.

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org

https://clicktime.symantec.com/a/1/nN3YNjTD37Z9bk8efCYXsWHpyw8ViK61Q8Dz1AzUt
no=?d=cQ4KQMo02NQvJ7GQxkZHfn9YbOkOTiGLFwgAhzovU-ksifF97AFzeTEl3fKU1c4flMJM5M
Qa4SYfNOuCB5-Y29jyEtL2_9KBxlVmHB_-8X_yPT3Gd1KBASJgcwXjKaIjjc7h8rFYLmo4FmmjdQ
DJfQcxl_q00tAfBZTdTqkwLD4b__i1PLIwekimsAKnCEc7M1LQPr1uSNB-FjHnEcF14WbG_18ILS
XzHM34tK_cdKnINlfFOEvMSGXK7LVBeRjiRGTuodckiUppT5eIbtRZNKo6R8hoXcUzy-yTZ21EbW
651pPGEqEwRb1Qpu9J0tLL6DExVNq6euprfMtWQTwjpQGvzkg5KO26pXSnafFpMBxblo_G0EcAZE
MPzGWZrQxxtD8_wSHTTO7-9MbzrQGF8qAWuuFbGW-M220s2HRhgU8qz_qZtto%3D&u=https%3A%
2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[Ryan Sleevi]

On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> This isn't a CA-issue because the risk associated with non-compliance isn't
> defined yet.

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

""Mozilla MAY, at its sole discretion, decide to disable (partially or
fully) or remove a certificate at any time and for any reason. This may
happen immediately or on a planned future date. Mozilla will disable or
remove a certificate if the CA demonstrates ongoing or egregious practices
that do not maintain the expected level of service or that do not comply
with the requirements of this policy.""

Sounds like the risk is well-defined and documented.

> From what I've heard here, the risk is distrust or loss of EV
> indicators, which is distrust-like. That's a pretty big thing to push back
> on the CA for a non-security issue. Thus, I think the risk of missing the
> underscore revocation date needs to be discussed here so everyone,
> including
> website operators and the relying parties, know first-hand what the risks
> of
> the CA missing the deadline are.

Any and every qualification or failure to abide by the program requirements
comes with it the risk of sanction, up to, and including, distrust.

It sounds like you're looking for a way for CAs to make a cost/benefit
analysis as to whether it's more beneficial to them to violate
requirements, by having a clearer guarantee what it will cost them if they
intentionally do so, versus what they may gain from their Subscribers. That
doesn't really seem aligned with the incentives of the ecosystem or the
relying parties, since CAs (and their Subscribers) are not able to, on
purely technical level, evaluate the cost or impact to Relying Parties,
since Relying Parties include every possible entity that trusts that root.

> If the risk is that there is a note on the
> audit, that is an acceptable risk. If the risk is a loss of the
> root...probably less so. Pushing the question back to the CA without
> better
> discussion by the browsers makes finding a solution or understanding the
> risks impossible.

While I think it's positive and encouraging to see CAs acknowledge that
their audits exist to disclose non-conformities/qualifications, I don't
think it should be seen as legitimizing or accepting that intentional
non-conformities/qualifications are desirable. A well-run CA should strive
to have zero qualifications, findings, or non-conformities - not because
they were able to convince their auditor that they weren't issues / were
minor, but because they operated above and beyond reproach, and there were
literally no issues. Anything short of that is an indicator that a CA is
failing in its role as a trusted steward, and repeated failures seem
reasonable to discuss sanction or distrust. CAs (and their sub-CAs) with a
pattern of incidents on the incident dashboard (
https://wiki.mozilla.org/CA/Incident_Dashboard and
https://wiki.mozilla.org/CA/Closed_Incidents ) probably have the greatest
risk of sanction, given the pre-existing patterns of non-compliance.

[Jeremy Rowley]

That’s not well defined as there are various grades below that. Is the plan to remove any CA that doesn’t comply with this requirement?

From: Ryan Sleevi <ry...@sleevi.com>
Sent: Friday, December 7, 2018 2:26 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: CA Communication: Underscores in dNSNames

[Jeremy Rowley]

I only ask because telling people to go back to the CA and work something out isn’t a great answer when the retort is that the CA will be distrusted if they don’t. Either the customer doesn’t replace all their certs and they are made non-functional by revocation or the certs are distrusted because the CA isn’t operational anymore. Telling people to go have the CA cover the risk when those are the two options seems like we’re avoiding the public discussion.

[Ryan Sleevi]

On Fri, Dec 7, 2018 at 4:35 PM Jeremy Rowley <jeremy...@digicert.com>
wrote:

> I only ask because telling people to go back to the CA and work something
> out isn’t a great answer when the retort is that the CA will be distrusted
> if they don’t. Either the customer doesn’t replace all their certs and they
> are made non-functional by revocation or the certs are distrusted because
> the CA isn’t operational anymore. Telling people to go have the CA cover
> the risk when those are the two options seems like we’re avoiding the
> public discussion.
>

Why not? It's fundamentally the CA taking the risk on when deciding whether
or not to meet the requirements of the programs that they participate in -
whether technical, policy, or contractual. If a customer wanted to ask a CA
to break a contractual requirement, isn't it ultimately the CA they should
be asking?

I think we're in agreement that, regardless, the CA MUST receive a
qualified audit. There's seemingly no defense that if they fail to revoke,
it should be a qualification, and there's even an argument that the
issuance itself should have been a qualification (and result in their
auditor re-evaluating these material facts, such as under AT-C 205.A54-A57
regarding revisions to opinions in light of subsequent events and
application guidance).

It's unclear what you expect to result from a public discussion, so perhaps
it would be helpful if you could clarify. It sounds like you're looking for
a blanket rubric for which to ignore the requirements of the Baseline
Requirements, so that the rubric can then be applied customer requests, and
determine whether or not these individual customers justify violating the
BRs. A good CA would acknowledge the rubric is, in fact, zero - zero
violations is the "justified" case, and everything else is the risk case.
Alternatively, it may be a desire that a rubric should exist, a priori to
any violations, so as to help determine whether a violation is justified,
even when the stated goal is zero violations.

If you look at public discussions, think about what the goals are of the
Incident Response template, which is about understanding how the CA's
processes failed. If you were to imagine intentionally violating the BRs,
knowingly, it seems like an incident response template would be far more
damning for that CA's operational competencies. That's not to suggest to
CAs its better to ask forgiveness than permission - a CA that ignored
changes in the BRs, clearly communicated (as Wayne mentioned in the
original post), also seems likely to have an incident report template that
is quite damning.

Using the experiences from the SHA-1 exception process, the only formalized
exception process, you can see that even in those limited cases, there was
significant skepticism towards the reasons. I would think that any proposal
for exceptions minimally achieve that degree of transparency, but would be
equally damning if those justifications were the same as those used for
SHA-1 - as the SHA-1 exception process "should" have revealed that those
are not, in fact, seen as legitimate.

If it helps to imagine this as a "How would this incident be received if it
became part of a Wiki page that listed a series of ongoing violations", I
think any CA contemplating not meeting the required transition date should
be asking "How many issues have I (or my sub-CAs) had under
https://wiki.mozilla.org/CA/Incident_Dashboard and
https://wiki.mozilla.org/CA/Closed_Incidents ). And there are definitely
some CAs that do not look to great in that light.

[pilgr...@gmail.com]

Fair enough

Impact is this:

As a retail organization we are in a moratorium till 1/2/2019 this happens every year. So nothing is being done that may jeopardize selling of widgets!

A process was put in place for 2wayssl where we'd name the cert based on what it does (so 2wayssl_to_from.domain.com) which we would then use for our own and partner vendor applications.

the scope of the main project if ~120 certs across a similar number of vendors. One of the home grown applications also hardcode the name of the certificate into the application and will require not only certificate update in coordination with the vendors but code changes on 120 certs in 12 days.

The project owners claim that timeline is impossible, and deploying 30 day validity certs is a similar level of effort without the code changes, and even that may not be possible.

This particular application is how we link with our partners for activation and generates ~2b per year in revenue.

To be perfectly clear here. We are 100% on board with a depreciation of the underscore (once we learned there was and issue with them from our CA we started restricting their issuance) The issue is I tell application owners this needs to be done, they want to know why they aren't even getting the 90 days they'd get if these were depreciated less aggressively (same they had for SHA1) for something that has not been a problem till now, and does not pose a security vulnerability.

As it sits from CA alerting us to the final outcome we got 44 days, 31 of which are over a holiday moratorium.


So for full scope: 260 certs out of compliance in my enterprise (out of ~17,000 current valid certs)

Of those 120 are problematic to replace in time, but could easily be done by the end of Q1

If I could get browser blessing to give us at least Q1 to finish this it would make the entire world a much better place for me :)

[Matt Palmer]

On Fri, Dec 07, 2018 at 08:13:24AM -0800, pilgrim2223--- via dev-security-policy wrote:
> As a retail organization we are in a moratorium till 1/2/2019 this happens
> every year. So nothing is being done that may jeopardize selling of
> widgets!

Choosing to not do something is, itself, doing something.

> The project owners claim that timeline is impossible, and deploying 30 day
> validity certs is a similar level of effort without the code changes, and
> even that may not be possible.

By a strict reading of the BRs, these missued certificates should have been
revoked within, at most, five days. If future problems are identified, that
may happen. So I suggest you talk to your project owners, apprise them of
the situation, and take steps to allow your systems to be able to react in
line with this potential timeline.

> To be perfectly clear here. We are 100% on board with a depreciation of
> the underscore (once we learned there was and issue with them from our CA
> we started restricting their issuance)

This is not a change in the rules (the BRs have always forbidden this type
of issuance), nor is it even a change in external circumstance (new research
results showing something that was thought to be safe wasn't). Your CA sold
you something they shouldn't have, and which they should have known they
shouldn't have. If you're unhappy with what your CA sold you, I would
recommend discussing the problem with them, perhaps with the assistance of
your legal team.

> now, and does not pose a security vulnerability.

I assume you've got something to back up that statement, beyond "I can't
think of any way this could be a security vulnerability". There are more
implementations in heaven and earth than are dreamt of in your philosophy,
and all that.

- Matt

[Richard Moore]

> the scope of the main project if ~120 certs across a similar number of vendors. One of the home grown applications also hardcode the name of the certificate into the application and will require not only certificate update in coordination with the vendors but code changes on 120 certs in 12 days.

It seems likely to me that these applications won't actually support OCSP and updating any CRLs in use may well be a manual process too. So, if the certificates were revoked, would your applications actually notice at all? It's quite different from them expiring which is coded into the certificate itself.

Kind Regards

Rich

[Alex Cohn]

On Sat, Dec 8, 2018 at 5:01 AM Richard Moore via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
>
> > the scope of the main project if ~120 certs across a similar number of vendors. One of the home grown applications also hardcode the name of the certificate into the application and will require not only certificate update in coordination with the vendors but code changes on 120 certs in 12 days.
>

> It seems likely to me that these applications won't actually support OCSP and updating any CRLs in use may well be a manual process too. So, if the certificates were revoked, would your applications actually notice at all? It's quite different from them expiring which is coded into the certificate itself.

Even if these apps support revocation checking, their root stores
might contain one or more ancient roots that are no longer needed by
any WebPKI certificate, and could therefore be removed from BR scope
and continue issuing underscore-containing certificates.

When SHA1 was deprecated, Sectigo (née Comodo) requested root stores
remove one of their roots [1], taking it out of scope for the BRs, and
continued issuing "legacy" SHA1 certificates off of that root. Sectigo
has also published a list of certificates containing underscores they
will be revoking [2]; conspicuously absent from that list are four of
these legacy SHA1 certificates [3].

Perhaps pilgrim2222's company (Verizon?) could convince a CA to do
something similar here?

Best,
Alex

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1208461
[2]: https://misissued.com/batch/41/
[3]: https://crt.sh/?id=701056092, https://crt.sh/?id=700688392,
https://crt.sh/?id=701055930, https://crt.sh/?id=700688392

[pilgr...@gmail.com]

thanks for the suggestions.

We are exploring the OCSP and CRL checks. It has potential.


As to getting certs from a different root, that wouldn't help us. We have no Technical reason to keep underscored certs and are happy to get rid of them, it is simply the effort required and the timeline given that are an issue.

[raha...@gmail.com]

[Buschart, Rufus]

Hello!

It would be helpful, if the CA/B or Mozilla could publish a document on its web pages to which we can redirect our customers, if they have technical questions about this underscore issue. Right now, I can only tell them, that they are forbidden because the ballot to explicitly allow them failed, but not really why. Especially since the first result in Google for "underscore domain name" is a StackOverflow article (https://stackoverflow.com/a/2183140/1426535) stating that it is technically perfectly okay and also RFC 5280 says "These characters [underscore and at-sign] often appear in Internet addresses. Such addresses MUST be encoded using an ASN.1 type that supports them."

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.b...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy <dev-security-...@lists.mozilla.org> Im Auftrag von rahat3858--- via dev-security-policy
> Gesendet: Montag, 10. Dezember 2018 01:45
> An: mozilla-dev-s...@lists.mozilla.org
> Betreff: Re: CA Communication: Underscores in dNSNames

>
> On Monday, November 12, 2018 at 3:19:17 PM UTC-8, Wayne Thayer wrote:

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Hello!
>
> It would be helpful, if the CA/B or Mozilla could publish a document on
> its web pages to which we can redirect our customers, if they have
> technical questions about this underscore issue. Right now, I can only tell
> them, that they are forbidden because the ballot to explicitly allow them
> failed, but not really why. Especially since the first result in Google for
> "underscore domain name" is a StackOverflow article (
> https://stackoverflow.com/a/2183140/1426535) stating that it is
> technically perfectly okay and also RFC 5280 says "These characters
> [underscore and at-sign] often appear in Internet addresses. Such
> addresses MUST be encoded using an ASN.1 type that supports them."
>

There's definitely been a lot of back and forth on this topic. It's unclear
if you're looking for a clearer statement about why they're forbidden or
where they're forbidden.

If the question is where they are forbidden,
https://tools.ietf.org/html/rfc5280#section-4.2.1.6

When the subjectAltName extension contains a domain name system
> label, the domain name MUST be stored in the dNSName (an IA5String).
> The name MUST be in the "preferred name syntax", as specified by
> Section 3.5 of [RFC1034] and as modified by Section 2.1 of
> [RFC1123]. Note that while uppercase and lowercase letters are
> allowed in domain names, no significance is attached to the case. In
> addition, while the string " " is a legal domain name, subjectAltName
> extensions with a dNSName of " " MUST NOT be used. Finally, the use
> of the DNS representation for Internet mail addresses
> (subscriber.example.com instead of subsc...@example.com) MUST NOT
> be used; such identities are to be encoded as rfc822Name. Rules for
> encoding internationalized domain names are specified in Section 7.2.


If the question is "why", then the answer is "Because the preferred name
syntax forbids them"
If the question is "Why does the preferred name syntax forbid them", that
is answered in RFC 1035, Section 2.3.1

https://tools.ietf.org/html/rfc1035#section-2.3.1

> The DNS specifications attempt to be as general as possible in the rules
> for constructing domain names. The idea is that the name of any
> existing object can be expressed as a domain name with minimal changes.



However, when assigning a domain name for an object, the prudent user
> will select a name which satisfies both the rules of the domain system
> and any existing rules for the object, whether these rules are published
> or implied by existing programs.



For example, when naming a mail domain, the user should satisfy both the
> rules of this memo and those in RFC-822. When creating a new host name,
> the old rules for HOSTS.TXT should be followed. This avoids problems
> when old software is converted to use domain names.



[ABNF omitted here]



Note that while upper and lower case letters are allowed in domain
> names, no significance is attached to the case. That is, two names with
> the same spelling but different case are to be treated as if identical.



The labels must follow the rules for ARPANET host names. They must
> start with a letter, end with a letter or digit, and have as interior
> characters only letters, digits, and hyphen. There are also some
> restrictions on the length. Labels must be 63 characters or less.


That is, the choice for how host names are expressed (A/AAAA, for example)
are derived from the syntax restrictions from HOSTS.TXT, which traces
through to the rules of ARPANET host names. The answer for "Why" is thus
"To ensure backwards compatibility with existing applications, and ensure
an unambiguous representation".

What I mean by "unambiguous" is, for example, the discussion about case
sensitivity. A DNS label is 8-byte clean, but a hostname uses the LDH rule.
If Client A interpreted "eXaMpLe.CoM" differently than Client B did - for
example, Client A used the existing HOSTS.TXT/ARPANET syntax and got one
host, while Client B used a case-sensitive algorithm - you could end up
with client confusion and incompatibility. This isn't theoretical either -
the IDNA 2003/2008/transitional issues have shown real confusion that can
arise with competing encodings.

You can find more about the terminology in
https://tools.ietf.org/html/rfc7719 if you want, but hopefully that
clarifies the "Why" - it has **always** been forbidden, just like it has *
*always** been forbidden to encode email addresses in DNS, and instead
require they use the RFC 822 syntax.

[Wayne Thayer]

On Sat, Dec 8, 2018 at 12:50 PM pilgrim2223--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> thanks for the suggestions.
>
> We are exploring the OCSP and CRL checks. It has potential.
>

> Have you determined if these applications perform revocations checks, or
if those checks can be blocked?

[Jakob Bohm]

On 10/12/2018 18:09, Ryan Sleevi wrote:
> On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Hello!
>>
>> It would be helpful, if the CA/B or Mozilla could publish a document on
>> its web pages to which we can redirect our customers, if they have
>> technical questions about this underscore issue. Right now, I can only tell
>> them, that they are forbidden because the ballot to explicitly allow them
>> failed, but not really why. Especially since the first result in Google for
>> "underscore domain name" is a StackOverflow article (
>> https://stackoverflow.com/a/2183140/1426535) stating that it is
>> technically perfectly okay and also RFC 5280 says "These characters
>> [underscore and at-sign] often appear in Internet addresses. Such
>> addresses MUST be encoded using an ASN.1 type that supports them."
>>
>
> There's definitely been a lot of back and forth on this topic. It's unclear
> if you're looking for a clearer statement about why they're forbidden or
> where they're forbidden.
>

It is clear that Rufus is looking for a link to the deprecation ballot,
rather than the old (failed) non-deprecation ballot.

> If the question is where they are forbidden,
> https://tools.ietf.org/html/rfc5280#section-4.2.1.6
>
> When the subjectAltName extension contains a domain name system
>> label, the domain name MUST be stored in the dNSName (an IA5String).
>> The name MUST be in the "preferred name syntax", as specified by
>> Section 3.5 of [RFC1034] and as modified by Section 2.1 of
>> [RFC1123]. Note that while uppercase and lowercase letters are
>> allowed in domain names, no significance is attached to the case. In
>> addition, while the string " " is a legal domain name, subjectAltName
>> extensions with a dNSName of " " MUST NOT be used. Finally, the use
>> of the DNS representation for Internet mail addresses
>> (subscriber.example.com instead of subsc...@example.com) MUST NOT
>> be used; such identities are to be encoded as rfc822Name. Rules for
>> encoding internationalized domain names are specified in Section 7.2.
>

The huge mess comes from the fact that this requirement of not
using the underscore character (which is actually used in some
RFC-specified DNS names labels, though for special purposes) was
buried in a complicated reference to two old RFCs, each of which
in turn describe that particular restriction in a complicated and
indirect way.

Furthermore, Section 4.2.1.6 of RFC5280 applies only to
SubjectAltNames, not to DNS names placed directly in the Subject
Distinguished Name in the certificate. Thus this particular
restriction on DNS names to which certificates can be issued only
became effective as a side effect of deprecating TLS certificates
without SubjectAltNames.

This made it completely unclear to most people that DNS labels
with underscores were not permitted in certificates. Thus the
restriction was not widely known outside the CA/root program
discussion groups until the rapid sunset was announced in November.

>
> If the question is "why", then the answer is "Because the preferred name
> syntax forbids them"
> If the question is "Why does the preferred name syntax forbid them", that
> is answered in RFC 1035, Section 2.3.1
>
> https://tools.ietf.org/html/rfc1035#section-2.3.1
>
>> The DNS specifications attempt to be as general as possible in the rules
>> for constructing domain names. The idea is that the name of any
>> existing object can be expressed as a domain name with minimal changes.
>
>
>
> However, when assigning a domain name for an object, the prudent user
>> will select a name which satisfies both the rules of the domain system
>> and any existing rules for the object, whether these rules are published
>> or implied by existing programs.
>
>
>
> For example, when naming a mail domain, the user should satisfy both the
>> rules of this memo and those in RFC-822. When creating a new host name,
>> the old rules for HOSTS.TXT should be followed. This avoids problems
>> when old software is converted to use domain names.
>
>
>
> [ABNF omitted here]
>
>

Note that this ABNF is one of only two places expressing the
restriction that is now being vigorously enforced 30 years later.

And that ABNF isn't even applicable due to RFC1123.

>
> Note that while upper and lower case letters are allowed in domain
>> names, no significance is attached to the case. That is, two names with
>> the same spelling but different case are to be treated as if identical.
>
>
>
> The labels must follow the rules for ARPANET host names. They must
>> start with a letter, end with a letter or digit, and have as interior
>> characters only letters, digits, and hyphen. There are also some
>> restrictions on the length. Labels must be 63 characters or less.
>

And this paragraph is the second place, which is also not entirely
applicable due to RFC1123.

The prohibition of "_" is expressed solely by not mentioning it as
permitted.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Ryan Sleevi]

On Tue, Dec 18, 2018 at 8:19 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 10/12/2018 18:09, Ryan Sleevi wrote:

> > On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> >> Hello!
> >>
> >> It would be helpful, if the CA/B or Mozilla could publish a document on
> >> its web pages to which we can redirect our customers, if they have
> >> technical questions about this underscore issue. Right now, I can only
> tell
> >> them, that they are forbidden because the ballot to explicitly allow
> them
> >> failed, but not really why. Especially since the first result in Google
> for
> >> "underscore domain name" is a StackOverflow article (
> >> https://stackoverflow.com/a/2183140/1426535) stating that it is
> >> technically perfectly okay and also RFC 5280 says "These characters
> >> [underscore and at-sign] often appear in Internet addresses. Such
> >> addresses MUST be encoded using an ASN.1 type that supports them."
> >>
> >
> > There's definitely been a lot of back and forth on this topic. It's
> unclear
> > if you're looking for a clearer statement about why they're forbidden or
> > where they're forbidden.
> >
>

> It is clear that Rufus is looking for a link to the deprecation ballot,
> rather than the old (failed) non-deprecation ballot.
>

Thanks for sharing your interpretation. I don't think that is an accurate
summary, but it's useful to understand your perspective and how you
interpret things.

> > If the question is where they are forbidden,
> > https://tools.ietf.org/html/rfc5280#section-4.2.1.6
> >
> > When the subjectAltName extension contains a domain name system
> >> label, the domain name MUST be stored in the dNSName (an IA5String).
> >> The name MUST be in the "preferred name syntax", as specified by
> >> Section 3.5 of [RFC1034] and as modified by Section 2.1 of
> >> [RFC1123]. Note that while uppercase and lowercase letters are
> >> allowed in domain names, no significance is attached to the case.
> In
> >> addition, while the string " " is a legal domain name,
> subjectAltName
> >> extensions with a dNSName of " " MUST NOT be used. Finally, the use
> >> of the DNS representation for Internet mail addresses
> >> (subscriber.example.com instead of subsc...@example.com) MUST NOT
> >> be used; such identities are to be encoded as rfc822Name. Rules for
> >> encoding internationalized domain names are specified in Section
> 7.2.
> >
>

> The huge mess comes from the fact that this requirement of not
> using the underscore character (which is actually used in some
> RFC-specified DNS names labels, though for special purposes) was
> buried in a complicated reference to two old RFCs, each of which
> in turn describe that particular restriction in a complicated and
> indirect way.
>

I find your summary interesting. I presume, then, that you feel that the
need to use DNS is buried in complicated references to old RFCs, much as it
would be how HTTP works or, for that matter, how ASN.1 works. It's
certainly true that, as we build complex systems, we stand on the shoulder
of giants, and as we build code and systems, we layer them. I think it's
rather misguided and ignorant to suggest that, because a document is
referenced by another document, it somehow becomes complicated, or that the
age matters. Were that the case, we'd presume the Baseline Requirements
would include everything from the IP specification to the ASN.1
specification, and everything in between, and then lament at how anyone is
supposed to understand or maintain the salient bits of this 10,000 page
document.

Furthermore, Section 4.2.1.6 of RFC5280 applies only to
> SubjectAltNames, not to DNS names placed directly in the Subject
> Distinguished Name in the certificate. Thus this particular
> restriction on DNS names to which certificates can be issued only
> became effective as a side effect of deprecating TLS certificates
> without SubjectAltNames.
>

If you're speaking to this side-effect being placed in 20 years ago, yes,
sure, then it's a side-effect, and the industry has had nearly twenty years
to contemplate the implications. The use of commonName within the context
of TLS was very much a 'hack', emerging both from the lack of X.509v3 (and
it's generic extension mechanism) and a repurposing of an existing OID in
the absence of the X.500 Global DIT (with would have otherwise set the
formatting restrictions). But it is inaccurate and revisionist to suggest
that this was a restriction on DNS names expressed through certificates -
as the underlying restriction itself comes from the host name form. That
is, 5280 is restating existing policy, not introducing new policy, in the
hope that people would understand, rather than entrench deeper into their
misunderstanding.

This made it completely unclear to most people that DNS labels
> with underscores were not permitted in certificates. Thus the
> restriction was not widely known outside the CA/root program
> discussion groups until the rapid sunset was announced in November.
>

This is equally and demonstrably wrong. This discussion goes back years, as
do the relevant standards discussions. I understand why there may be a
vested personal interest in this narrative, but it's not an accurate one.
The discussions over Ballot 202 - which themselves go back some time - and
the ultimate resolution provided clear statement about the present
expectations.


> > [ABNF omitted here]
> >
> >
>

> Note that this ABNF is one of only two places expressing the
> restriction that is now being vigorously enforced 30 years later.
>
> And that ABNF isn't even applicable due to RFC1123.
>

This is an interesting argument to make, and while it sounds compelling, is
rather demonstrably weak. It's a poor suggestion that the legitimacy of a
requirement is based on the number of times or places it is specified, and
similarly to suggest that somehow it's not relevant for the discussion,
when the requirement calls out explicitly both 1034 and 1123 to draw
attention to the fact that 1123 modified 1034.

The weakest part of this argument is that it can be perfectly applied to
arguing that neither BER nor DER make sense.

That's because restrictions/requirements on encoding BER are only expressed
in one place (X.690), and because the requirements of DER supersede (but
integrate) those of BER, we can say the requirements on BER aren't even
applicable due to DER.

> > The labels must follow the rules for ARPANET host names. They must
> >> start with a letter, end with a letter or digit, and have as interior
> >> characters only letters, digits, and hyphen. There are also some
> >> restrictions on the length. Labels must be 63 characters or less.
> >
>

> And this paragraph is the second place, which is also not entirely
> applicable due to RFC1123.
>
> The prohibition of "_" is expressed solely by not mentioning it as
> permitted.
>

Here, we've moved from "isn't even applicable" to "not entirely
applicable", a subtle shift in the broad statements. While it's true that
1123 modifies 1034, 5280 is at pains to explicitly call that out, so it
hardly supports the argument that this is somehow new and novel. And it's
interesting that the choice is that because it's a positive statement
(permitted characters), not negative statement (prohibited), it's somehow
more difficult.

I'm curious, would the same lament apply to string types (which are defined
in terms of their permitted characters), protocols like IP (defined in
terms of their permitted semantics), or things like ASN.1 (defined in terms
of permitted values)?


The reality is that the arguments in favor of permitting it have always
been weak, and it's always been clear that it was not permitted. The
argument constantly being advanced seems to circle around a few things:
1) I shouldn't have to read multiple specifications to implement complex
systems
- A poor argument, given that CAs have seemingly managed 'OCSP' or 'RSA
keys' (both separate specifications) on the implementation side, and seem
to have no problem producing overlapping CP/CPS (and RP agreement and
Subscriber agreements and a host of other documents) that somehow are meant
to define their systems
2) I don't understand why I should have to follow the specification
- An inquisitive and questioning mind is a good thing, but obstinate
intransigence is hardly that
3) It only told me what I was allowed to do, not what I wasn't allowed to do
- An approach that relies on understanding everything explicitly
prohibited is not a good approach for running critical Internet security
systems. A blacklist does not address security in the way that a whitelist
does. Unless it explicitly says something is permitted, the assumption
should be it's prohibited. If you even have to question - "It might mean
this" - it's something to be discussed publicly and clarified
4) OK, I acknowledge it was wrong, but now people are counting on me to
keep doing it
- The requirements on the Subscriber Agreement, and in the BRs, exist for
a reason. Since the beginning, the certificate ecosystem is one that has
expected agility - if something is misleading to RPs, it MUST be revoked.
It's the fundamental tradeoff of the PKI, which, similar to Kerberos,
allows severing of the RP<->CA online conversation for attestations, but
requires that the Subscriber<->CA channel be reliable (or, in Kerberos,
that the User<->KDC channel is reliable, allowing the severing of the
Server<->KDC channel)

There's zero point in trying to litigate this. It does not change the fact
that it was not permitted and has never been, and more importantly, reveals
an approach to security that's fundamentally incompatible with the Internet
scale. That's not to say no ambiguity exists whatsoever in these documents
- we should strive to clarify that whenever possible - but there's a vast
gulf between reasonable and unreasonable interpretations. If anything,
these areas of confusion are only revealed through greater transparency -
whether of certificates or practices - and those affected by this issue,
whether CAs or Subscribers, should instead be focused on how to bring about
greater transparency in policies and practices. By doing that, areas of
reasonable confusion can be identifed, and meaningful transition plans can
be applied.

But suggestions that this was somehow "hurried", when it was discussed for
years, is just factually and demonstrably wrong. And regardless of whether
customers of certain CAs understood it, the CAs themselves were expected
to, and the fault lies with them.

[Jakob Bohm]

Well he wanted that or another _single document_ that affected parties
can read, rather than trying to dig through the RFCs and mailing lists
themselves.

The simple fact that the leading experts on the subject disagreed on
the issue shows that the outcome wasn't obvious (the opposite outcome
would not have been obvious either).

It's the classic question if corner case behavior of a piece of code is a
feature or a bug, except it was English-language documents, not C-language
code.

The wording and structure of RFC5280 (and its predecessor RFC2459) is such
that it appears to state an encoding of DNS names, not a restriction to
ARPANET host names. For a subscriber or relying party developing and
deploying a system like the one described by pilgrim2223, everything after
the 2nd paragraph of 4.2.1.6 would look like ASN.1/DER encoding details to
be handled by the 3rd party TLS library, and such a subscriber would probably
believe it when both a Google search and their CA tells them it is A-OK.

Removing the "underscore mandatory" and "specific name X_Y mandatory" rules
from deployed systems without introducing security holes takes more than the
1 month they have given that the annual Thanksgiving-to-NewYears lockdown
has been mentioned in other global issues. (In fact this is the first
subscriber/RP interfering BR effective date hitting the Xmas season since
the SHA-1 deprecation).

[Wayne Thayer]

On Tue, Dec 18, 2018 at 3:47 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> Removing the "underscore mandatory" and "specific name X_Y mandatory"
> rules
> from deployed systems without introducing security holes takes more than
> the
> 1 month they have given that the annual Thanksgiving-to-NewYears lockdown
> has been mentioned in other global issues. (In fact this is the first
> subscriber/RP interfering BR effective date hitting the Xmas season since
> the SHA-1 deprecation).
>

> The only thing that's required by 15-Jan is that existing certificates
containing underscores need to be replaced with new ones with the same
dNSNames. The deadline for updating systems to remove dependencies on
underscores in certificates is 30-April.

The 15-Jan deadline was negotiated with holiday change freezes in mind. The
assumption was that these freezes end in early January, providing
sufficient time to perform a routine certificate replacement. While I
understand that the replacement is not necessarily as simple as it should
be for all affected systems, and in other cases it's simple but there are
lots of certificates to replace, I think this is really just highlighting
the lack of agility in existing enterprise systems that use
publicly-trusted certificates. Hopefully this "huge mess" will spur
improvements over time.

I am also struggling with the argument that "revoking these certificates
will cause a massive outage, but we can't replace them due to our change
freeze." Given this position, I sincerely hope that no severe zero-days are
released during the holidays.

[Buschart, Rufus]

> On Tue, Dec 18, 2018 at 8:19 AM Jakob Bohm via dev-security-policy < dev-secur...@lists.mozilla.org> wrote:
> > On 10/12/2018 18:09, Ryan Sleevi wrote:

> > > On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via
> > > dev-security-policy < dev-secur...@lists.mozilla.org> wrote:
> > >
> > >> Hello!
> > >>
> > >> It would be helpful, if the CA/B or Mozilla could publish a
> > >> document on its web pages to which we can redirect our customers,
> > >> if they have technical questions about this underscore issue. Right
> > >> now, I can only
> > tell
> > >> them, that they are forbidden because the ballot to explicitly
> > >> allow
> > them
> > >> failed, but not really why. Especially since the first result in
> > >> Google
> > for
> > >> "underscore domain name" is a StackOverflow article (
> > >> https://stackoverflow.com/a/2183140/1426535) stating that it is
> > >> technically perfectly okay and also RFC 5280 says "These characters
> > >> [underscore and at-sign] often appear in Internet addresses. Such
> > >> addresses MUST be encoded using an ASN.1 type that supports them."
> > >>
> > >
> > > There's definitely been a lot of back and forth on this topic. It's
> > unclear
> > > if you're looking for a clearer statement about why they're
> > > forbidden or where they're forbidden.
> > >
> >

> > It is clear that Rufus is looking for a link to the deprecation
> > ballot, rather than the old (failed) non-deprecation ballot.
> >
>
> Thanks for sharing your interpretation. I don't think that is an accurate summary, but it's useful to understand your perspective and
> how you interpret things.
>

Thank you very much for the good and constructive discussion that followed my question. The main problem I had with this underscore issue is, that the first hit at Google links to a SO article (https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it/2183140#2183140) which is a little bit misleading, if not being red with a lot of care. But based on this discussion and the statement of Wayne I think everything is clear now. Thank you once again!

/Rufus