Open Bug 1523221 Opened 7 months ago Updated 2 months ago

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

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: jonathan, Assigned: gpki)

Details

(Whiteboard: [ca-compliance])

Attachments

(1 file)

22.93 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details

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

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

Assignee: wthayer → gpki
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(gpki)
Whiteboard: [ca-compliance]

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.

Flags: needinfo?(gpki)

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.)

Flags: needinfo?(gpki)

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.

Flags: needinfo?(gpki)

(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

Flags: needinfo?(gpki)

Provide the Incident Report

Flags: needinfo?(gpki)

(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.

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

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

Flags: needinfo?(wthayer)

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.

Flags: needinfo?(wthayer) → needinfo?(gpki)

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

(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)

Flags: needinfo?(gpki)
You need to log in before you can comment on or make changes to this bug.