1522080 - T-Systems: DFN-PKI - Non-IDNA 2003 IDNs, violation of RFC 5280

Status: RESOLVED INVALID

(CA Program :: CA Certificate Compliance, task)

Description

[Jürgen Brauckmann]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

DFN-PKI issued 4 certificates with IDNs wich do not conform to IDNA 2003, thus are not RFC 5280 compatible

Actual results:

incomplete syntax check

Expected results:

complete check for IDNA2003 conformance

Comment 1

[Jürgen Brauckmann]

DFN received a report claiming two certificates with IDN xn--gau-allianz-x6a.de were misissued. The problem report centers around handling of IDNs according to the BRs and RFC 5280, which references RFC 3490 (IDNA 2003) and does not allow IDNA 2008 which was introduced later by RFC 8399 as an update of RFC 5280.

Results of our investigation/conclusions:

• The claim of the problem report that xn--gau-allianz-x6a.de is not in IDNA 2003 format is correct.

• Question: Are ACE-labels not encoded as IDNA 2003 in certificates a misissuance under the Baseline Requirements? Yes, we think this is currently the case:

  • Baseline Requirements mandate conformance to exactly RFC 5280 and don't reference/allow any updates, e.g., RFC 8399

  • Chapter 7.2 of RFC 5280 https://tools.ietf.org/html/rfc5280#page-97 states:
    "Specifically, conforming implementations MUST perform the conversion operation specified in Section 4 of RFC 3490, with the following clarifications: ...."

  • So, IDNs must be converted according to the rules of RFC 3490

  • We, as a CA, don't perform the conversion mentioned in RFC 5280. We receive/process ACE-labels only. This means that our system is likely not meant by the wording "conforming implementations" of RFC 5280.

  • However, our systems have the technical means and generally the responsibility to check for correct input. So, we shall check/enforce IDNA 2003 ACE-labels.

• This case is quite interesting, as the German cc-TLD registry deNIC allows/registers IDNA 2008 names. The German letter “ß” (U+00DF, LATIN SMALL LETTER SHARP S), part of gauß-allianz.de/xn--gau-allianz-x6a.de is an especially problem-ridden part of the differences between IDNA 2003 and IDNA 2008. So, there are registered domain names which will never get certificates from conforming CAs under the current BRs.

• Current versions (as of 2019-01) of cablint and zlint do not detect this problem as they seem to use IDNA 2008-compliant libraries. zlint currently even references RFC 8399.

1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

2019-01-21, 10:54 CET: Root CA T-Systems forwards problem report (email) and reaches out to us via telephone.

2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

2019-01-21, 10:54 CET: Investigation started immediately after we received the problem report.

2019-01-21, 12:38 CET: We confirmed that our current PKI software checks for strict IDNA 2003 compliance and does not allow IDNA 2008. Affected certificates were issued in 2016 and in October 2018, when our then productive PKI software did no strict IDNA2003 check.

2019-01-21, afternoon: A check was started over all unrevoked unexpired certificates for similar problems.

2019-01-21, 15:47 CET: revocation of https://crt.sh/?id=19949789

2019-01-22, 08:23 CET: revocation of https://crt.sh/?id=55098906

2019-01-22, 10:30 CET: Check-run that was started on the previous afternoon discovers two more certificates with IDNA2003-non-compliant IDNs

2019-01-22, 15:07 CET: revocation of https://crt.sh/?id=841080254 and revocation of https://crt.sh/?id=1134286108

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

Additional IDN checks are in place since 2018-10-17. Since then, only IDNA 2003 compliant certificates can be issued.

4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

Four certificates with ACE-labels not encoded in IDNA 2003 in the subject alt name. First issuance 2016-05-20, last issuance 2019-10-09

5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

https://crt.sh/?id=19949789
https://crt.sh/?id=55098906
https://crt.sh/?id=841080254
https://crt.sh/?id=1134286108

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

When exploring ways to check IDN-encoding, we were first relying on cablint. We utilized cablint to check all existing certificates, and implemented pre-issuance linting.

Root cause of the misissuance was a missing adjustment between requirements according to RFC 5280 and the tools and measures used for checks. We did check back then that cablint does contain mechanisms for checking IDNs, but did not see that cablint itself did not do the right thing.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

We revoked all four affected certificates.

As part of incremental improvements to our PKI software, additional IDN checks were already introduced on 2018-10-17. Since then, IDNA 2003-encoding errors are detected and certificate issuance is prevented. At the time we added the additional IDN checks we were not aware that the earlier deployed cablint check did not catch IDNA 2003 encoding errors, hence we did not search for those encoding errors in our corpus of issued certificates at the time.

Comment 2

[Wayne Thayer]

Jürgen: thank you for providing this incident report. The discussion (linked below) has concluded that this issue is not a clear violation of Mozilla policy, so I am closing this as INVALID.

https://groups.google.com/d/msg/mozilla.dev.security.policy/ad6NfLGZ730/9yTm3iJgFAAJ