1523221 - GRCA: Misissued certificates - invalid CN, bad validity period, missing extensions

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Jonathan Rudenberg]

The following certificates issued by GRCA have an invalid commonName, validity period >825 days, and are missing the required EKU and SAN extensions:

https://crt.sh/?id=1143716165&opt=zlint
https://crt.sh/?id=1109742430&opt=zlint
https://crt.sh/?id=756069647&opt=zlint

Comment 1

[Wayne Thayer]

These don't appear to be intended for serverAuth, but lacking an EKU they are valid for serverAuth.

Please provide an incident report for this problem, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 2

[National Development Council]

Dear

These certificates are not used for TLS. These certificates are used in our e-government data exchange systems.
According to baseline requirement 7.1.2.3, extKeyUsage are required for a TLS certificate.
According to baseline requirement 7.1.2.4.2.1, subjectAltName are required for a TLS certificate.
In our concept, a certificate without extKeyUsage and subjectAltName are not qualified for TLS, and should not be considered a TLS certificate.

Comment 3

[Jonathan Rudenberg]

Mozilla's policy is very clear about this: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#11-scope

Certificates without an EKU extension are considered TLS serverAuth certificates and are in scope for the complete policy including all standards incorporated by reference (the Baseline Requirements, RFC 5280, etc.)

Comment 4

[National Development Council]

This issue are addressed in the CABForum at F2F meeting 44. We are also discussing the EKU issue with Microsoft now.
Since these certificates are used in our e-government service (not TLS), but there is no suitable EKU for general purpose digital signature and encryption.
GPKI are willing to put EKUs in all end-entity certificates, but as far as we know there is no international standard or IETF RFC has defined general purposed document signing and data encryption EKU.
The Document Signing EKU(1.3.6.1.4.1.311.10.3.12) and Encryption File System(EFS) EKU(1.3.6.1.4.1.311.10.3.4) are not general purposed EKU.
1.Document Signing EKU(1.3.6.1.4.1.311.10.3.12) is used in signing Microsoft Software Office Document and is not suitable for general-purposed document or message signing.
2.Enctiption File System(EFS) EKU(1.3.6.1.4.1.311.10.3.4) is used to by Microsoft Windows Encryption File System(EFS), is suitable for general-purposed) file or data encryption.

We completely understand and respect the Mozilla's Root Store Policy. Although these certificates used in e-government service don't have EKU, we have technically constraints that these certificates have no domain name / IP address in SANs and CN. Technically these certificate can't be used in TLS, and browser would not confuse with these certificate. We would like to kindly ask that these certificates are not treated as misissued certificates.

We would make the decision about the EKU issue as soon as possible.

Comment 5

[Wayne Thayer]

(In reply to National Development Council from comment #4)

Thank you for the response.

This issue are addressed in the CABForum at F2F meeting 44. We are also discussing the EKU issue with Microsoft now.
Since these certificates are used in our e-government service (not TLS), but there is no suitable EKU for general purpose digital signature and encryption.
GPKI are willing to put EKUs in all end-entity certificates, but as far as we know there is no international standard or IETF RFC has defined general purposed document signing and data encryption EKU.
The Document Signing EKU(1.3.6.1.4.1.311.10.3.12) and Encryption File System(EFS) EKU(1.3.6.1.4.1.311.10.3.4) are not general purposed EKU.
1.Document Signing EKU(1.3.6.1.4.1.311.10.3.12) is used in signing Microsoft Software Office Document and is not suitable for general-purposed document or message signing.

It appears that Adobe also has their own document signing EKU - 1.2.840.113583.1.1.5 Why can't both the Microsoft and Adobe EKUs be included in these certificates? Adobe also supports the codeSigning EKU [1], and that would exempt these certificates from Mozilla policy.

2.Enctiption File System(EFS) EKU(1.3.6.1.4.1.311.10.3.4) is used to by Microsoft Windows Encryption File System(EFS), is suitable for general-purposed) file or data encryption.

What software other than Windows needs to rely on these certificates but fails if the EKUs listed above are asserted?

We completely understand and respect the Mozilla's Root Store Policy. Although these certificates used in e-government service don't have EKU, we have technically constraints that these certificates have no domain name / IP address in SANs and CN. Technically these certificate can't be used in TLS, and browser would not confuse with these certificate. We would like to kindly ask that these certificates are not treated as misissued certificates.

I understand that there is a reason, but these are still misissued certificates. Please provide an incident report as requested in comment #1.

We would make the decision about the EKU issue as soon as possible.

What is your timeline for remediating this problem?

[1] https://www.adobe.com/devnet-docs/acrobatetk/tools/DigSig/changes.html

Comment 6

[National Development Council]

Attachment: Misissuance#Incident ReportBug 1523221.docx

Provide the Incident Report

Comment 7

[National Development Council]

(In reply to Wayne Thayer [:wayne] from comment #5)

(In reply to National Development Council from comment #4)

Thank you for the response.

This issue are addressed in the CABForum at F2F meeting 44. We are also discussing the EKU issue with Microsoft now.
Since these certificates are used in our e-government service (not TLS), but there is no suitable EKU for general purpose digital signature and encryption.
GPKI are willing to put EKUs in all end-entity certificates, but as far as we know there is no international standard or IETF RFC has defined general purposed document signing and data encryption EKU.
The Document Signing EKU(1.3.6.1.4.1.311.10.3.12) and Encryption File System(EFS) EKU(1.3.6.1.4.1.311.10.3.4) are not general purposed EKU.
1.Document Signing EKU(1.3.6.1.4.1.311.10.3.12) is used in signing Microsoft Software Office Document and is not suitable for general-purposed document or message signing.

It appears that Adobe also has their own document signing EKU - 1.2.840.113583.1.1.5 Why can't both the Microsoft and Adobe EKUs be included in these certificates? Adobe also supports the codeSigning EKU [1], and that would exempt these certificates from Mozilla policy.

2.Enctiption File System(EFS) EKU(1.3.6.1.4.1.311.10.3.4) is used to by Microsoft Windows Encryption File System(EFS), is suitable for general-purposed) file or data encryption.

What software other than Windows needs to rely on these certificates but fails if the EKUs listed above are asserted?

Some vendors in ROC are fully complying with the definition of EKU extension field in RFC 5280, and implement the Certificate Validation Software in full compliance with the Certification Path Validation Algorithm defined in Section 6 of RFC 5280, if we include EKUs in the End-Entity Certificate like Microsoft's custom Encryption File System (EFS) EKU (1.3.6.1.4.1.311.10.3.4), but this EKU OID can only be used for Windows File Encryption Systtem, not for General Messages or Documents Encryption / Decryption, when our citizens use such certificates for Encryption/Decryption of general Messages or Documents, such a Certificate Validation Software implemented in accordance with the RFC 5280 standard will consider this certificate to be used for the wrong purpose.

Comment 8

[Wayne Thayer]

Thank you for the incident report. I have begun a discussion of the issue and the solution proposed in the incident report on the mozilla.dev.security.policy list: https://groups.google.com/d/msg/mozilla.dev.security.policy/WtR8bkPfcnk/VqHL45ECDAAJ

Comment 9

[Ryan Sleevi]

Wayne: The conversation died down. Did you get what you wanted? Do we know next steps here?

Comment 10

[Wayne Thayer]

Mozilla policy version 2.7 is likely to include an EKU requirement that goes into effect in April 2020, 9 months prior to the timeline proposed by GRCA: https://groups.google.com/d/msg/mozilla.dev.security.policy/5lAI-8lkQbM/1D392GR1BQAJ

Can GRCA meet this deadline? If not, please post an explanation in the policy discussion thread linked above.

Comment 11

[Ryan Sleevi]

Emailed POCs on 2019-07-08 regarding this issue, highlighting https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed

Comment 12

[National Development Council]

(In reply to Wayne Thayer [:wayne] from comment #10)

Mozilla policy version 2.7 is likely to include an EKU requirement that goes into effect in April 2020, 9 months prior to the timeline proposed by GRCA: https://groups.google.com/d/msg/mozilla.dev.security.policy/5lAI-8lkQbM/1D392GR1BQAJ

Can GRCA meet this deadline? If not, please post an explanation in the policy discussion thread linked above.

It is difficult for us to complete ahead of April 2020.
I have post my explanation.(https://groups.google.com/d/msg/mozilla.dev.security.policy/5lAI-8lkQbM/1D392GR1BQAJ)

Comment 13

[Wayne Thayer]

The completion of version 2.7 of Mozilla's policy has been delayed due to other priorities. Meanwhile, in the last update to the mozilla.dev.security.policy thread, a GPKI representative stated:

We need to define our own Document Signing EKU and data encryption EKU, and coordinate all subordinate Cas(Five CAs) and application system’s owners(more than 2,000 application systems).
It needs a whole year to implement this. Therefore, after multiple evaluations, it is decided to officially add the EKU to the user certificate on January 1, 2021.
It is difficult for us to complete ahead of April 2020.

Please provide an update on the progress GPKI is making on implementing these changes. For example, have new EKUs been defined? Is GPKI on track to add the EKU by January 1, 2021?

Comment 14

[National Development Council]

We have already negotiated with many departments and vendors, and scheduled to hold a meeting with our sub CAs to define new EKUs in November.
We will add EKUs to the user certificate on January 1, 2021.

Comment 15

[Wayne Thayer]

GRCA: Please provide an update on the remediation of this issue.

Comment 16

[National Development Council]

We will follow the Mozilla's Root Store Policy(section 5.2).
All EE certificates we issue on or after July 1, 2020 will include an EKU.

Comment 17

[Wayne Thayer]

It appears that this incident has been remediated and GRCA has a plan to comply with the update Mozilla policy regarding EKUs in EE certs, so this bug can be resolved.