zmap
BUG: lint "e_ext_san_rfc822_name_present" should only be applied to SSL/TLS subscriber certificates
Certificate with potential issue
As part of a wider test we checked all of our CA certificates by Zlint ver.3.1.0 and we could identify a potential issue with the following certificate:
- e-Szigno SSL CA 2014
- https://crt.sh/?id=4569808
The summarized result of the zlint test
| LEVEL | # OCCURRENCES | DETAILS |
+-------+---------------+-----------------------------------------------------+
| info | 2 | n_ca_digital_signature_not_set |
| | | n_sub_ca_eku_missing |
| warn | 0 | - |
| error | 1 | e_ext_san_rfc822_name_present |
| fatal | 0 | - |
The scope of lint "e_ext_san_rfc822_name_present"
We checked the scope of the lint "e_ext_san_rfc822_name_present" on GitHub:
- https://github.com/zmap/zlint/blob/master/v3/lints/cabf_br/lint_ext_san_rfc822_name_present.go
- https://github.com/zmap/zlint/blob/master/v3/lints/cabf_br/lint_ext_san_rfc822_name_present_test.go
The zlint documentation provides the following description regarding this lint:
Name: "e_ext_san_rfc822_name_present",
Description: "The Subject Alternate Name extension MUST contain only 'dnsName' and 'ipaddress' name types.",
Citation: "BRs: 7.1.4.2.1",
Our interpretation
In our understanding the cited requirement should only be applied for subscriber certificates, as it can be seen in the title of the subsection:
- "7.1.4.2 Subject Information - Subscriber Certificates"
This requirement does not exist for CA certificates in the following subsection:
- 7.1.4.3 Subject Information - Root Certificates and Subordinate CA Certificates
There is no any stipulation for the SAN extension in case of CA certificates.
The issue may be caused by that the problematic CA certificate was issued in 2014, when version 1.1.7 of the BR was in effect. This BR version contains near the same requirements for the Subscriber Certificates in section 9.2 as the current one, but it is not evident from the wording that these requirements should be applied only for subscriber certificates. This ambiguity was present until BR version 1.4.8 (adopted by Ballot 199), although it seems to be clear from other requirements of this subsection that these can not be applied to CA certificates.
Our proposal
If you agree with our interpretation we suggest to run this lint only in case of an SSL/TLS subscriber certificate. In case of CA certificates ZLint should return with an "NA" output.
Other interpretation?
Could you please provide your views in this matter?
So, for the context of the current requirements, it does sound like your description is correct, and this lint should only apply to end-entity certificates.
However, in the context of ongoing requirements, the intent of the certificate profiles work going on in the validation subcommittee is to make clear this is forbidden for CA certificates, because it's very much problematic.
Our CA certificates have never included dnsname or ipaddress values in the SAN extension, but due to a local requirement, we had to enter the CA contact email address in the CA certificates. It was included in both the SN and the SAN.
Our CA certificates issued after 2014 do not include email address in either the SN field or the SAN extension.
@sleevi when do you think that those ongoing requirements will make it through to publishing? If it's awhile off (I dunno, six months or more...?) then I would be amenable to "fixing" this and then sunsetting it when the new requirements are published.
It's sort of a letter-of-the-law versus the spirit-of-the-law type situation. The current wording appears to allow it (letter-of-the-law) but it shouldn't and it's going to be fixed (spriit-of-the-law).
https://github.com/zmap/zlint/issues/583#issuecomment-826379236 covers the timing.