1973341 - eMudhra emSign PKI Services: Policy Document Inconsistency

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Naveen Kumar ML]

Preliminary Incident Report

Summary

• Incident description:
  A publicly trusted TLS certificate was issued for CN=msmeranchi.nic.in with an RSA key size of 4048 bits, based on a CSR submitted by the subscriber. The RSA key pair was generated by the customer and met the CA/Browser Forum Baseline Requirements, which require a minimum RSA key size of 2048 bits.
  Both our CP/CPS v1.14 (valid at the time of issuance) and the current CP/CPS v1.19 only reference "RSA 2048" under the certificate profile for end-entity certificates, and this may be interpreted as a specific requirement for only that key size. This perspective would be reinforced when in same CP/CPS we explicitly list RSA key sizes of 2048 or 4096 bits for Root and Subordinate CA certificates. The absence of specific key lengths above 2048 in the documentation for end entities led to an inconsistency between the practice and documentation while theoretically being in compliance with baseline requirements. No security risk was introduced. Planned corrective action is to update our CP/CPS to clarify that RSA key sizes are permitted above 2048, and the profile document was meant to indicate a minimum as per our practices and enforcement via linting.
  In the same report, the researcher also pointed out a formatting inconsistency in the Code Signing OV profile, where the key length is written as "RSA 20484096". This issue has been acknowledged and will be addressed in the upcoming CP/CPS update.

• Relevant policies:

1. CA/Browser Forum Baseline Requirements for TLS Server Certificates. Section 6.1.5 Key sizes
2. eMudhra CP/CPS v1.14 (effective at the time of issuance) Section 11. Appendix B: Certificate Profiles
3. eMudhra CP/CPS v1.19 (current) Section 11. Appendix B: Certificate Profiles
4. Internal CA issuance practice (minimum RSA key size: 2048 bits)

• Source of incident disclosure:
  External researcher reported the concern via email to [e-mail] on June 19, 2025. We acknowledged and responded to the report within 24 hours, indicating that the CP/CPS would be updated to clarify acceptable RSA key lengths.

Comment 1

[Rob Stradling]

(In reply to Naveen Kumar ML from comment #0)

Planned corrective action is to update our CP/CPS to clarify that RSA key sizes are permitted above 2048, and the profile document was meant to indicate a minimum as per our practices and enforcement via linting.

Naveen, you're absolutely correct that the TLS BRs permit RSA key sizes above 2048, but please note the following requirement in BR 6.1.1.3 (added in ballot SC73, effective 2024-07-01):

"In the case of Debian weak keys vulnerability (https://wiki.debian.org/SSLkeys), the CA SHALL reject all keys found at https://github.com/cabforum/Debian-weak-keys/ for each key type (e.g. RSA, ECDSA) and size listed in the repository."

That official CABForum Debian weak key repository currently covers RSA key sizes 2048, 3072, 4096, and 8192. For other RSA key sizes, the following requirement applies:

"For all other keys meeting the requirements of Section 6.1.5, with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys"

Q1: Does eMudhra "reject Debian weak keys" for the usual RSA key sizes (2048, 3072, 4096, 8192)?

Q2: Has eMudhra generated or obtained additional Debian weak key blocklists in order to "reject Debian weak keys" for unusual RSA key sizes such as 4048?

---

Just FYI, Sectigo disallows unusual RSA key sizes, by blocking issuance when we encounter the following dwklint WARNING during pre-issuance linting with pkimetal:

https://crt.sh/?id=13302141823&opt=pkimetal
"dwklint v2.0.1:
WARNING: No Debian weak key blocklist is available for this key algorithm/size"

Comment 2

[Naveen Kumar ML]

(In reply to Rob Stradling from comment #1)

Here are answers to your questions

Q1: Does eMudhra "reject Debian weak keys" for the usual RSA key sizes (2048, 3072, 4096, 8192)?

The systems check for Debian weak keys using pkimetal now and prior to its release use the github repository for checking weak keys for the usual key sizes.

Q2: Has eMudhra generated or obtained additional Debian weak key blocklists in order to "reject Debian weak keys" for unusual RSA key sizes such as 4048?

This specific certificate was issued May 2024 (prior to Ballot) and at that time the system didn’t block the issuance of a 4048 bit key length (we have not obtained additional weak keys for this odd key length).
Post October last year, the system was modified to only allow standard key sizes but the documentation hasn’t been explicit about this for sometime now.

We will now align the documentation to be explicit about accepting only standard key sizes.
We would appreciate your perspective on the following:

1. As we prepare the full incident report, in your opinion, do we now have two incidents or still just one?
2. Do we introduce more risk to the ecosystem if we revoke the unexpired certificates identified in this incident? All of them comply with the Baseline Requirements. They all comply with our internal policies - it is only our published Policy which we determined was an errata.
   Any perspective/insight on this would be helpful.

We will publish a full incident report for this one by tomorrow.

Comment 3

[Wayne]

I am not Rob, however I did file this original certificate problem report. Below is the full copy:

Hi,

Was looking at unusual RSA key lengths and noticed the following certificate:

SHA256: 32519ac08a6c739c952e2764c8d81464a0906633d8167a9985c8a67d9894f1f2

DN: CN=msmeranchi.nic.in

Key length: 4048

Now, this is not against the baseline requirements but on checking the CP/S for the validity period (2024-05-28) I noticed 1.14 covers this certificate: https://repository.emsign.com/cps/CP-CPS-v1.14.pdf

Which for some reason only states 'RSA 2048' under public key in the certificate profiles, but give a variety for ECC (256, 384, 521). I noticed the CP/S got updated to allow for 2048 and 4096 in roots and intermediaries, but otherwise this limitation still applies to 1.19. There's a typo in Code Signing OV for RSA 20484096 too.

On that note any >2048b certificate isn't compliant currently.

- Wayne

I am looking forward to the full incident report.

Comment 4

[Naveen Kumar ML]

We are in the process of finalizing our full incident report. Given the detailed internal review and coordination required, we will be submitting the report within the next 24 hours.

Comment 5

[Rob Stradling]

(In reply to Naveen Kumar ML from comment #2)

Post October last year, the system was modified to only allow standard key sizes but the documentation hasn’t been explicit about this for sometime now.

We will now align the documentation to be explicit about accepting only standard key sizes.
We would appreciate your perspective on the following:

1. As we prepare the full incident report, in your opinion, do we now have two incidents or still just one?

I don't think a second incident bug is needed. The documentation (CP/CPS versions v1.14 to v1.19) explicitly says that only RSA-2048 is permitted, and RSA-2048 is a "standard key size" for which eMudhra has been checking for Debian weak keys. You didn't need "to be explicit about accepting only standard key sizes", because you were already being explicit about only accepting one standard key size.

One purpose of my comment 1 was to help ensure that eMudhra's corrective action for this incident doesn't lead to a second incident.

2. Do we introduce more risk to the ecosystem if we revoke the unexpired certificates identified in this incident? All of them comply with the Baseline Requirements. They all comply with our internal policies - it is only our published Policy which we determined was an errata.
   Any perspective/insight on this would be helpful.

We will publish a full incident report for this one by tomorrow.

A CA's published policy is what matters, since that's the documentation that Relying Parties have the opportunity to review.

TBR 4.9.1.1 says:
"With the exception of Short-lived Subscriber Certificates, the CA SHOULD revoke a
certificate within 24 hours and MUST revoke a Certificate within 5 days and use the
corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs:
...
12. The CA is made aware that the Certificate was not issued in accordance with these
Requirements or the CA’s Certificate Policy or Certification Practice Statement
(CRLReason #4, superseded);"

Revocation is never optional when 4.9.1.1(12) applies, even when there is perceived risk to the ecosystem. Failure to revoke on time is always an incident, and such "delayed revocation" incidents have additional incident reporting requirements.

Comment 6

[Naveen Kumar ML]

(In reply to Rob Stradling from comment #5)

(In reply to Naveen Kumar ML from comment #2)

Post October last year, the system was modified to only allow standard key sizes but the documentation hasn’t been explicit about this for sometime now.

We will now align the documentation to be explicit about accepting only standard key sizes.
We would appreciate your perspective on the following:

1. As we prepare the full incident report, in your opinion, do we now have two incidents or still just one?

I don't think a second incident bug is needed. The documentation (CP/CPS versions v1.14 to v1.19) explicitly says that only RSA-2048 is permitted, and RSA-2048 is a "standard key size" for which eMudhra has been checking for Debian weak keys. You didn't need "to be explicit about accepting only standard key sizes", because you were already being explicit about only accepting one standard key size.

One purpose of my comment 1 was to help ensure that eMudhra's corrective action for this incident doesn't lead to a second incident.

2. Do we introduce more risk to the ecosystem if we revoke the unexpired certificates identified in this incident? All of them comply with the Baseline Requirements. They all comply with our internal policies - it is only our published Policy which we determined was an errata.
   Any perspective/insight on this would be helpful.

We will publish a full incident report for this one by tomorrow.

A CA's published policy is what matters, since that's the documentation that Relying Parties have the opportunity to review.

TBR 4.9.1.1 says:
"With the exception of Short-lived Subscriber Certificates, the CA SHOULD revoke a
certificate within 24 hours and MUST revoke a Certificate within 5 days and use the
corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs:
...
12. The CA is made aware that the Certificate was not issued in accordance with these
Requirements or the CA’s Certificate Policy or Certification Practice Statement
(CRLReason #4, superseded);"

Revocation is never optional when 4.9.1.1(12) applies, even when there is perceived risk to the ecosystem. Failure to revoke on time is always an incident, and such "delayed revocation" incidents have additional incident reporting requirements.

Thank you for your feedback. We have revoked all 449 unexpired certificates that did not comply with our policy document. A full incident report on the delayed revocation will be submitted.

Comment 7

[Naveen Kumar ML]

Full Incident Report

Summary

• CA Owner CCADB unique ID:
  A005678

• Incident description:
  A publicly trusted TLS certificate was issued for CN=msmeranchi.nic.in with an RSA key size of 4048 bits, based on a CSR submitted by the subscriber. The RSA key pair was generated by the customer and met the CA/Browser Forum Baseline Requirements, which require a minimum RSA key size of 2048 bits.
  Both our CP/CPS v1.14 (valid at the time of issuance) and the current CP/CPS v1.19 only reference "RSA 2048" under the certificate profile for end-entity certificates, and this may be interpreted as a specific requirement for only that key size. This perspective would be reinforced when in same CP/CPS we explicitly list RSA key sizes of 2048 or 4096 bits for Root and Subordinate CA certificates. The absence of specific key lengths above 2048 in the documentation for end entities led to an inconsistency between the practice and documentation while theoretically being in compliance with baseline requirements. No security risk was introduced. Planned corrective action is to update our CP/CPS to clarify that RSA key sizes are permitted above 2048, and the profile document was meant to indicate a minimum as per our practices and enforcement via linting.
  In the same report, the researcher also pointed out a formatting inconsistency in the Code Signing OV profile, where the key length is written as "RSA 20484096". This issue has been acknowledged and will be addressed in the upcoming CP/CPS update.

• Timeline summary:

  • Non-compliance start date: Certificate issuance date May 28, 2024 06:17:58 UTC
  • Non-compliance identified date: June 19, 2025 12:06:58 UTC
  • Non-compliance end date: June 21, 2025

• Relevant policies:

  • CA/Browser Forum Baseline Requirements for TLS Server Certificates. Section 6.1.5 Key sizes
  • eMudhra CP/CPS v1.14 (effective at the time of issuance) Section 11. Appendix B: Certificate Profiles
  • eMudhra CP/CPS v1.19 (current) Section 11. Appendix B: Certificate Profiles
  • Internal CA issuance practice (minimum RSA key size: 2048 bits)

• Source of incident disclosure:
  External researcher reported the concern via email to [e-mail] on June 19, 2025. We acknowledged and responded to the report within 24 hours, indicating that the CP/CPS would be updated to clarify acceptable RSA key lengths.

Impact

• Total number of certificates:
  1823 (Out of these certificates, 1,814 have a 4096-bit key size, 6 have a 3072-bit key size, 2 have an 8192-bit key size and 1 certificate has a 4048-bit key size)
• Total number of "remaining valid" certificates:
  449
• Affected certificate types:
  End-entity TLS server certificate
• Incident heuristic:
  CP/CPS documentation inconsistency
• Was issuance stopped in response to this incident, and why or why not?:
  No. The certificate met Baseline Requirements and internal minimum RSA key size practice. Issuance processes continued with 2048 bit keys, and documentation corrections planned.
• Analysis:
  The incident arose due to inaccurate documentation of acceptable RSA key sizes in the CP/CPS end-entity certificate profile. No system failure occurred, as the certificate was technically compliant.
• Additional considerations:
  No security impact to remaining set of certificates as all of the remaining valid certificates have a 3072, 4096 and 8192 bit key size and have undergone Debian weak key check as part of the linting process. While originally no revocation was planned, subsequent to community clarification on interpretation of BR, we went ahead and revoked the unexpired certificates.

Timeline

(All times in UTC)
2024-05-28 06:17:58 : Certificate issued for CN=msmeranchi.nic.in
2025-06-19 12:06:58 : Researcher reported issue
2025-06-19 12:30:00 : Report acknowledged and review of practices initiated
2025-06-19 14:00:00 : Compliance began review of BRs and internal policies on key size limitations; concern raised to PKI team
2025-06-19 15:30:00 : PKI team confirmed key was not disallowed as it exceeds 2048-bit RSA minimum as per BR requirements.
2025-06-19 15:00:00 : Compliance and PKI team submitted report of observations to management
2025-06-20 05:00:00 : Compliance drafted response for researcher
2025-06-20 06:30:00 : Response sent to problem reporting including our observation and action to update CP/CPS
2025-06-21 10:33:00 : Preliminary report submitted
2025-06-21 11:30:00 : Internal review of documentation and profiles initiated
2025-06-26 03:00:00 : As per re-review of BR requirements based on community feedback and revocation plan was initiated by the compliance team.
2025-06-26 07:00:00 : PKI team revoked 449 unexpired certificates.

Related Incidents

Bug	Date	Description
1962829	2025-04-25	Policy document inconsistent.
1886876	2024-03-21	Deviation from CP/CPS.

Root Cause Analysis

Contributing Factor 1: CP/CPS certificate profile wording gap

• Description:
  End-entity certificate profile referenced RSA 2048 but did not clarify that larger key sizes were acceptable, leading to misinterpretation. Due to incomplete communication, feedback loop and human oversight a change made for the CA system was not updated to the policy document.
• Timeline:
  2023-08-30 : CP/CPS v1.14 published; End-entity certificate profile referenced only RSA 2048 without clarifying acceptance of larger RSA key sizes.
  2025-06-06 : Latest CP/CPS v1.19 published; documentation gap persisted in end-entity profile.
  2022-01-14 to 2023-08-30 and 2023-08-30 to 2025-06-06 : The documentation gap went unnoticed internally since January 2022, when we first issued an SSL certificate with a key size greater than 2048 bits. Our internal policy allowed RSA keys of 2048 bits or larger, the gap was not noticed during initial documentation review and this error kept cascading through subsequent iteration of the document.
  2025-06-19 : External researcher reported the issue related to issuance of certificate with RSA 4048-bit key.
  2025-06-19 : CA acknowledged report, initiated corrective action, and planned CP/CPS update to clarify acceptable RSA key sizes.
  2025-06-26 : Revoked 449 unexpired certificates.
• Detection:
  Reported by external researcher on June 19, 2025 12:06:58 UTC.
• Interaction with other factors:
  Rob Stradling of Sectigo pointed out asking if we check for Debian weak keys and our policy regarding acceptance of odd key lengths. While the system does check for Debian weak keys as part of the linting, the system was not proactively blocking the acceptance of an odd key length even though compliant with BR.
• Root Cause Analysis methodology used:
  5-Whys

Lessons Learned

• What went well:
  Quick acknowledgment and response.
• What didn’t go well:
  Documentation clarity could have prevented concern, inconsistency went undetected for a long period of time which led to practices being inconsistency to policy.
• Where we got lucky:
  The key was stronger than the minimum required, and no security risk occurred.
• Additional:
  Need to proactively ensure CP/CPS text fully aligns with practices and ensure tighter compliance checks

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Update CP/CPS to clarify specific acceptable RSA key sizes for end-entity certificates in line with practice and correct formatting	Prevent	Root Cause # 1	CP/CPS update published	2025-07-15	In progress

Appendix

Relevant CPS Policy Documents:
https://repository.emsign.com/cps/CP-CPS-v1.14.pdf
https://repository.emsign.com/cps/CP-CPS-v1.19.pdf

Affected certificates are published in the attachment.

Comment 8

[Naveen Kumar ML]

Attachment: Annexure - Cert List.xlsx

Comment 9

[Naveen Kumar ML]

Following action items are anticipated to be completed on 2025-07-15:

1. Update CP/CPS to clarify specific acceptable RSA key sizes for end-entity certificates in line with practice and correct formatting

Comment 10

[Naveen Kumar ML]

Weekly Status Update

The CP/CPS has been updated with the relevant modifications to clarify acceptable RSA key sizes for end-entity certificates. The revised CP/CPS, Version 1.20, has been published in the emSign repository on 2025-07-08.

Comment 11

[Naveen Kumar ML]

Weekly Update

No further action required at this time.

Comment 12

[Naveen Kumar ML]

Weekly Update

No further action required at this time.

Comment 13

[Naveen Kumar ML]

Weekly Update

No further action required at this time.

Comment 14

[Naveen Kumar ML]

Report Closure Summary

• Incident description:
  On May 28, 2024, a publicly trusted TLS certificate was issued for CN=msmeranchi.nic.in using an RSA key size of 4048 bits, based on a CSR submitted by the subscriber. Although the key size met CA/Browser Forum Baseline Requirements, both CP/CPS v1.14 (valid at the time) and v1.19 only referenced “RSA 2048” for end-entity certificates, creating ambiguity about acceptance of larger key sizes. This inconsistency between documented policy and operational practice was identified by an external researcher on June 19, 2025. The report also noted a formatting error in the Code Signing OV profile (“RSA 20484096”). Investigation confirmed the issues, and corrective actions were planned, including updates to clarify permitted key sizes and fix formatting inconsistencies. The non-compliance period ended on June 21, 2025, with the conclusion of the investigation and initiation of remediation.

• Incident Root Cause(s):
  The CP/CPS v1.14 referenced only RSA 2048-bit keys without clarifying acceptance of larger sizes, causing misinterpretation. Due to incomplete communication and human oversight, policy updates did not reflect CA system changes permitting larger keys. This documentation gap persisted from 2022 until it was reported externally in June 19, 2025. As a result, certificates with 4096-bit keys were issued without clear policy alignment.
  The CP/CPS certificate profile wording gap persisted from August 2023 through June 2025: the end-entity section explicitly stated only “RSA 2048” and omitted any mention of permissible larger key sizes. This documentation oversight, combined with human and process lapses during policy updates, caused a misinterpretation between practice and published policy.

• Remediation description:
  The CP/CPS was revised to explicitly specify the acceptable RSA key sizes for end-entity certificates. Formatting inconsistencies were addressed to enhance clarity and accessibility. These updates have been officially published.
  We have updated the CP/CPS to explicitly clarify acceptable RSA key sizes above 2048 bits for end-entity certificates and corrected the formatting inconsistency in the Code Signing OV profile. The revised CP/CPS v1.20 was published in the emSign repository on July 8, 2025. Additionally, all 449 unexpired certificates that did not comply with the clarified policy were revoked.

• Commitment summary:
  All preventive actions disclosed in the incident report have been completed. These include updating the Certificate Policy (CP) and Certification Practice Statement (CPS) to clarify acceptable RSA key sizes for end-entity certificates, ensuring alignment with current practices and correcting formatting for greater clarity.

All Action Items disclosed in this report have been completed as described, and we request its closure.

Comment 15

[incident-reporting]

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2025-08-18.