Repository navigation
SC-XX: Reorganize key quality checking and add ECDSA small private scalar check - #683
Draft
aarongable wants to merge 2 commits into
Draft
aarongable wants to merge 2 commits into
aarongable wants to merge 2 commits into
Conversation
aww-aww
reviewed
Oct 22, 2026
dzacharo
reviewed
Oct 23, 2026
|
|
||
| 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](#722-crl-and-crl-entry-extensions)) if one or more of the following occurs: | ||
|
|
||
| 6. The Certificate no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking) (CRLReason #4, superseded); |
Contributor
There was a problem hiding this comment.
We must consider how the changes introduced in section 6.1.6 will not trigger the revocation requirement for certificates issued before the cut-off dates.
| RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. Additionally, the public exponent SHOULD be in the range between 2^16 + 1 and 2^256 - 1. The modulus SHOULD also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. [Source: Section 5.3.3, NIST SP 800-89] | ||
| For RSA public keys, the CA MUST: | ||
|
|
||
| - Ensure that the public exponent is an odd number equal to 3 or more. |
Contributor
There was a problem hiding this comment.
Suggested change
| - Ensure that the public exponent is an odd number equal to 3 or more. | |
| - Ensure that the public exponent is an odd number equal to 3 or more. Effective 2027-03-15, ensure that the public exponent is equal to 65537 (2^16 + 1) or more. |
Happy for a shorter effective date if there are no concerns by others.
|
|
||
| 1. The Subordinate CA requests revocation in writing; | ||
| 2. The Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization; | ||
| 3. The Issuing CA obtains evidence that the Subordinate CA's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking); |
Contributor
There was a problem hiding this comment.
Same here. We must consider how the changes introduced in section 6.1.6 will not trigger the revocation requirement for CA certificates issued before the cut-off dates.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Move most requirements around CAs rejecting certificate requests from Section 6.1.1.3 (Subscriber Key Pair Generation) to Section 6.1.6 (Public key parameters generation and quality checking). This ensures that these requirements (e.g. that the key not be vulnerable to Fermat factorization) apply equally to both Subscriber and CA keys.
In order to merge the contents of 6.1.1.3 with the existing contents of 6.1.6, reorganize and rephrase the requirements slightly. This introduces no new requirements, but hopefully makes the existing requirements easier to read and understand.
Finally, with an effective date of 2027-01-15, require that CAs check for ECDSA keys with private scalars less than 256. This is analogous to the existing recommendation that CAs check for RSA keys with factors less that 752, and would have prevented the recent compromise of 8 ECDSA Subordinate CA Certificate Private Keys whose private scalars all fit in one byte each.