Spec compliance bug fixes by cpu · Pull Request #445 · rustls/rcgen

cpu · 2026-08-10T20:37:22Z

I let claude loose to do a review of bugs similar to #444 and it came up with several findings I confirmed myself. As an experiment I let it write the unit tests and fixes and then reviewed them myself to satisfaction. In summary:

We were using the wrong time for CRL InvalidityDate
We allowed an empty CRL distribution points URI list that would produce a misencoding
Cert. params with only key_usages or crl_distribution_points wouldn't produce a cert w/ those extensions
There was a way to write a CRL entry with reasonCode==0, which is invalid
PKCS_RSA_PSS_SHA256 salt encoding was wrong at least two ways

The last commit drops some crate-internal RSASSA-PSS bits rather than try to fix the salt length bugs. I think that's the right call and we can revive it (correctly) in #417 when someone has the time/energy.

I opted for a "write an ignored test that catches the bug and fails without the fix, then write the fix and unignore the test" approach here because I wanted to keep the LLM on the rails. If folks prefer we can squash each of those paired commits into just one. LMK.

djc

Nice, LGTM!

I'd be in favor of squashing both commits for each fix into one.

RFC 5280 §5.3.2 defines the invalidity date CRL entry extension as InvalidityDate ::= GeneralizedTime, not the Time CHOICE used for validity and revocation dates. Using write_dt_utc_or_generalized meant any invalidity date between 1950 and 2049 was encoded with a UTCTime tag, producing an invalid extension that strict parsers reject. Write the date as GeneralizedTime unconditionally and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Serializing a CrlDistributionPoint with no URIs produced an empty fullName GeneralNames, violating GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName (RFC 5280 §4.2.1.13). Return the new Error::EmptyCrlDistributionPointUris from certificate and CRL serialization instead of emitting invalid DER, and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Add key_usages and crl_distribution_points to the should_write_exts gate in serialize_der_with_signer. Previously a certificate whose params requested only one of those extensions was silently issued with no extensions at all, because the gate predicted emptiness from a different set of fields than write_extensions actually writes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Filter Unspecified out of the reason code once, before both the presence check and the extension write, instead of applying the filter only in the presence check. Previously reason_code: Some(Unspecified) combined with an invalidity date wrote an ENUMERATED 0 reasonCode extension, which RFC 5280 §5.3.1 says should be absent. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

PKCS_RSA_PSS_SHA256 has been pub(crate) and excluded from SignatureAlgorithm::iter() (and therefore from_oid) since its introduction, so it is unreachable by users. Its encoding was also doubly wrong: it wrote saltLength 20 explicitly even though RFC 4055 declares saltLength [2] INTEGER DEFAULT 20 (the same X.690 §11.5 violation as the explicit cA FALSE bug), and the declared 20-byte salt did not match the 32-byte salt ring/aws-lc-rs actually use for RSA_PSS_SHA256 signatures. Remove the algorithm, its RsaPss params writer, the key pair loading branches, the id-RSASSA-PSS OID constant, and the commented-out references, rather than shipping latent bugs. PSS support can be reintroduced properly if there is demand. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cpu · 2026-08-11T13:38:19Z

I'd be in favor of squashing both commits for each fix into one.

Done.

cpu · 2026-08-10T20:37:22Z

I let claude loose to do a review of bugs similar to #444 and it came up with several findings I confirmed myself. As an experiment I let it write the unit tests and fixes and then reviewed them myself to satisfaction. In summary:

We were using the wrong time for CRL InvalidityDate
We allowed an empty CRL distribution points URI list that would produce a misencoding
Cert. params with only key_usages or crl_distribution_points wouldn't produce a cert w/ those extensions
There was a way to write a CRL entry with reasonCode==0, which is invalid
PKCS_RSA_PSS_SHA256 salt encoding was wrong at least two ways

The last commit drops some crate-internal RSASSA-PSS bits rather than try to fix the salt length bugs. I think that's the right call and we can revive it (correctly) in #417 when someone has the time/energy.

I opted for a "write an ignored test that catches the bug and fails without the fix, then write the fix and unignore the test" approach here because I wanted to keep the LLM on the rails. If folks prefer we can squash each of those paired commits into just one. LMK.

djc

Nice, LGTM!

I'd be in favor of squashing both commits for each fix into one.

RFC 5280 §5.3.2 defines the invalidity date CRL entry extension as InvalidityDate ::= GeneralizedTime, not the Time CHOICE used for validity and revocation dates. Using write_dt_utc_or_generalized meant any invalidity date between 1950 and 2049 was encoded with a UTCTime tag, producing an invalid extension that strict parsers reject. Write the date as GeneralizedTime unconditionally and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Serializing a CrlDistributionPoint with no URIs produced an empty fullName GeneralNames, violating GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName (RFC 5280 §4.2.1.13). Return the new Error::EmptyCrlDistributionPointUris from certificate and CRL serialization instead of emitting invalid DER, and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Add key_usages and crl_distribution_points to the should_write_exts gate in serialize_der_with_signer. Previously a certificate whose params requested only one of those extensions was silently issued with no extensions at all, because the gate predicted emptiness from a different set of fields than write_extensions actually writes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Filter Unspecified out of the reason code once, before both the presence check and the extension write, instead of applying the filter only in the presence check. Previously reason_code: Some(Unspecified) combined with an invalidity date wrote an ENUMERATED 0 reasonCode extension, which RFC 5280 §5.3.1 says should be absent. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

PKCS_RSA_PSS_SHA256 has been pub(crate) and excluded from SignatureAlgorithm::iter() (and therefore from_oid) since its introduction, so it is unreachable by users. Its encoding was also doubly wrong: it wrote saltLength 20 explicitly even though RFC 4055 declares saltLength [2] INTEGER DEFAULT 20 (the same X.690 §11.5 violation as the explicit cA FALSE bug), and the declared 20-byte salt did not match the 32-byte salt ring/aws-lc-rs actually use for RSA_PSS_SHA256 signatures. Remove the algorithm, its RsaPss params writer, the key pair loading branches, the id-RSASSA-PSS OID constant, and the commented-out references, rather than shipping latent bugs. PSS support can be reintroduced properly if there is demand. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cpu · 2026-08-11T13:38:19Z

I'd be in favor of squashing both commits for each fix into one.

Done.

cpu · 2026-08-10T20:37:22Z

I let claude loose to do a review of bugs similar to #444 and it came up with several findings I confirmed myself. As an experiment I let it write the unit tests and fixes and then reviewed them myself to satisfaction. In summary:

We were using the wrong time for CRL InvalidityDate
We allowed an empty CRL distribution points URI list that would produce a misencoding
Cert. params with only key_usages or crl_distribution_points wouldn't produce a cert w/ those extensions
There was a way to write a CRL entry with reasonCode==0, which is invalid
PKCS_RSA_PSS_SHA256 salt encoding was wrong at least two ways

The last commit drops some crate-internal RSASSA-PSS bits rather than try to fix the salt length bugs. I think that's the right call and we can revive it (correctly) in #417 when someone has the time/energy.

I opted for a "write an ignored test that catches the bug and fails without the fix, then write the fix and unignore the test" approach here because I wanted to keep the LLM on the rails. If folks prefer we can squash each of those paired commits into just one. LMK.

djc

Nice, LGTM!

I'd be in favor of squashing both commits for each fix into one.

RFC 5280 §5.3.2 defines the invalidity date CRL entry extension as InvalidityDate ::= GeneralizedTime, not the Time CHOICE used for validity and revocation dates. Using write_dt_utc_or_generalized meant any invalidity date between 1950 and 2049 was encoded with a UTCTime tag, producing an invalid extension that strict parsers reject. Write the date as GeneralizedTime unconditionally and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Serializing a CrlDistributionPoint with no URIs produced an empty fullName GeneralNames, violating GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName (RFC 5280 §4.2.1.13). Return the new Error::EmptyCrlDistributionPointUris from certificate and CRL serialization instead of emitting invalid DER, and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Add key_usages and crl_distribution_points to the should_write_exts gate in serialize_der_with_signer. Previously a certificate whose params requested only one of those extensions was silently issued with no extensions at all, because the gate predicted emptiness from a different set of fields than write_extensions actually writes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Filter Unspecified out of the reason code once, before both the presence check and the extension write, instead of applying the filter only in the presence check. Previously reason_code: Some(Unspecified) combined with an invalidity date wrote an ENUMERATED 0 reasonCode extension, which RFC 5280 §5.3.1 says should be absent. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

PKCS_RSA_PSS_SHA256 has been pub(crate) and excluded from SignatureAlgorithm::iter() (and therefore from_oid) since its introduction, so it is unreachable by users. Its encoding was also doubly wrong: it wrote saltLength 20 explicitly even though RFC 4055 declares saltLength [2] INTEGER DEFAULT 20 (the same X.690 §11.5 violation as the explicit cA FALSE bug), and the declared 20-byte salt did not match the 32-byte salt ring/aws-lc-rs actually use for RSA_PSS_SHA256 signatures. Remove the algorithm, its RsaPss params writer, the key pair loading branches, the id-RSASSA-PSS OID constant, and the commented-out references, rather than shipping latent bugs. PSS support can be reintroduced properly if there is demand. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cpu · 2026-08-11T13:38:19Z

I'd be in favor of squashing both commits for each fix into one.

Done.

cpu · 2026-08-10T20:37:22Z

I let claude loose to do a review of bugs similar to #444 and it came up with several findings I confirmed myself. As an experiment I let it write the unit tests and fixes and then reviewed them myself to satisfaction. In summary:

We were using the wrong time for CRL InvalidityDate
We allowed an empty CRL distribution points URI list that would produce a misencoding
Cert. params with only key_usages or crl_distribution_points wouldn't produce a cert w/ those extensions
There was a way to write a CRL entry with reasonCode==0, which is invalid
PKCS_RSA_PSS_SHA256 salt encoding was wrong at least two ways

The last commit drops some crate-internal RSASSA-PSS bits rather than try to fix the salt length bugs. I think that's the right call and we can revive it (correctly) in #417 when someone has the time/energy.

I opted for a "write an ignored test that catches the bug and fails without the fix, then write the fix and unignore the test" approach here because I wanted to keep the LLM on the rails. If folks prefer we can squash each of those paired commits into just one. LMK.

djc

Nice, LGTM!

I'd be in favor of squashing both commits for each fix into one.

RFC 5280 §5.3.2 defines the invalidity date CRL entry extension as InvalidityDate ::= GeneralizedTime, not the Time CHOICE used for validity and revocation dates. Using write_dt_utc_or_generalized meant any invalidity date between 1950 and 2049 was encoded with a UTCTime tag, producing an invalid extension that strict parsers reject. Write the date as GeneralizedTime unconditionally and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Serializing a CrlDistributionPoint with no URIs produced an empty fullName GeneralNames, violating GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName (RFC 5280 §4.2.1.13). Return the new Error::EmptyCrlDistributionPointUris from certificate and CRL serialization instead of emitting invalid DER, and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Add key_usages and crl_distribution_points to the should_write_exts gate in serialize_der_with_signer. Previously a certificate whose params requested only one of those extensions was silently issued with no extensions at all, because the gate predicted emptiness from a different set of fields than write_extensions actually writes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Filter Unspecified out of the reason code once, before both the presence check and the extension write, instead of applying the filter only in the presence check. Previously reason_code: Some(Unspecified) combined with an invalidity date wrote an ENUMERATED 0 reasonCode extension, which RFC 5280 §5.3.1 says should be absent. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

PKCS_RSA_PSS_SHA256 has been pub(crate) and excluded from SignatureAlgorithm::iter() (and therefore from_oid) since its introduction, so it is unreachable by users. Its encoding was also doubly wrong: it wrote saltLength 20 explicitly even though RFC 4055 declares saltLength [2] INTEGER DEFAULT 20 (the same X.690 §11.5 violation as the explicit cA FALSE bug), and the declared 20-byte salt did not match the 32-byte salt ring/aws-lc-rs actually use for RSA_PSS_SHA256 signatures. Remove the algorithm, its RsaPss params writer, the key pair loading branches, the id-RSASSA-PSS OID constant, and the commented-out references, rather than shipping latent bugs. PSS support can be reintroduced properly if there is demand. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cpu · 2026-08-11T13:38:19Z

I'd be in favor of squashing both commits for each fix into one.

Done.

cpu · 2026-08-10T20:37:22Z

I let claude loose to do a review of bugs similar to #444 and it came up with several findings I confirmed myself. As an experiment I let it write the unit tests and fixes and then reviewed them myself to satisfaction. In summary:

We were using the wrong time for CRL InvalidityDate
We allowed an empty CRL distribution points URI list that would produce a misencoding
Cert. params with only key_usages or crl_distribution_points wouldn't produce a cert w/ those extensions
There was a way to write a CRL entry with reasonCode==0, which is invalid
PKCS_RSA_PSS_SHA256 salt encoding was wrong at least two ways

The last commit drops some crate-internal RSASSA-PSS bits rather than try to fix the salt length bugs. I think that's the right call and we can revive it (correctly) in #417 when someone has the time/energy.

I opted for a "write an ignored test that catches the bug and fails without the fix, then write the fix and unignore the test" approach here because I wanted to keep the LLM on the rails. If folks prefer we can squash each of those paired commits into just one. LMK.

djc

Nice, LGTM!

I'd be in favor of squashing both commits for each fix into one.

RFC 5280 §5.3.2 defines the invalidity date CRL entry extension as InvalidityDate ::= GeneralizedTime, not the Time CHOICE used for validity and revocation dates. Using write_dt_utc_or_generalized meant any invalidity date between 1950 and 2049 was encoded with a UTCTime tag, producing an invalid extension that strict parsers reject. Write the date as GeneralizedTime unconditionally and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Serializing a CrlDistributionPoint with no URIs produced an empty fullName GeneralNames, violating GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName (RFC 5280 §4.2.1.13). Return the new Error::EmptyCrlDistributionPointUris from certificate and CRL serialization instead of emitting invalid DER, and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Add key_usages and crl_distribution_points to the should_write_exts gate in serialize_der_with_signer. Previously a certificate whose params requested only one of those extensions was silently issued with no extensions at all, because the gate predicted emptiness from a different set of fields than write_extensions actually writes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Filter Unspecified out of the reason code once, before both the presence check and the extension write, instead of applying the filter only in the presence check. Previously reason_code: Some(Unspecified) combined with an invalidity date wrote an ENUMERATED 0 reasonCode extension, which RFC 5280 §5.3.1 says should be absent. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

PKCS_RSA_PSS_SHA256 has been pub(crate) and excluded from SignatureAlgorithm::iter() (and therefore from_oid) since its introduction, so it is unreachable by users. Its encoding was also doubly wrong: it wrote saltLength 20 explicitly even though RFC 4055 declares saltLength [2] INTEGER DEFAULT 20 (the same X.690 §11.5 violation as the explicit cA FALSE bug), and the declared 20-byte salt did not match the 32-byte salt ring/aws-lc-rs actually use for RSA_PSS_SHA256 signatures. Remove the algorithm, its RsaPss params writer, the key pair loading branches, the id-RSASSA-PSS OID constant, and the commented-out references, rather than shipping latent bugs. PSS support can be reintroduced properly if there is demand. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cpu · 2026-08-11T13:38:19Z

I'd be in favor of squashing both commits for each fix into one.

Done.

cpu · 2026-08-10T20:37:22Z

I let claude loose to do a review of bugs similar to #444 and it came up with several findings I confirmed myself. As an experiment I let it write the unit tests and fixes and then reviewed them myself to satisfaction. In summary:

We were using the wrong time for CRL InvalidityDate
We allowed an empty CRL distribution points URI list that would produce a misencoding
Cert. params with only key_usages or crl_distribution_points wouldn't produce a cert w/ those extensions
There was a way to write a CRL entry with reasonCode==0, which is invalid
PKCS_RSA_PSS_SHA256 salt encoding was wrong at least two ways

The last commit drops some crate-internal RSASSA-PSS bits rather than try to fix the salt length bugs. I think that's the right call and we can revive it (correctly) in #417 when someone has the time/energy.

I opted for a "write an ignored test that catches the bug and fails without the fix, then write the fix and unignore the test" approach here because I wanted to keep the LLM on the rails. If folks prefer we can squash each of those paired commits into just one. LMK.

djc

Nice, LGTM!

I'd be in favor of squashing both commits for each fix into one.

RFC 5280 §5.3.2 defines the invalidity date CRL entry extension as InvalidityDate ::= GeneralizedTime, not the Time CHOICE used for validity and revocation dates. Using write_dt_utc_or_generalized meant any invalidity date between 1950 and 2049 was encoded with a UTCTime tag, producing an invalid extension that strict parsers reject. Write the date as GeneralizedTime unconditionally and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Serializing a CrlDistributionPoint with no URIs produced an empty fullName GeneralNames, violating GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName (RFC 5280 §4.2.1.13). Return the new Error::EmptyCrlDistributionPointUris from certificate and CRL serialization instead of emitting invalid DER, and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Add key_usages and crl_distribution_points to the should_write_exts gate in serialize_der_with_signer. Previously a certificate whose params requested only one of those extensions was silently issued with no extensions at all, because the gate predicted emptiness from a different set of fields than write_extensions actually writes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Filter Unspecified out of the reason code once, before both the presence check and the extension write, instead of applying the filter only in the presence check. Previously reason_code: Some(Unspecified) combined with an invalidity date wrote an ENUMERATED 0 reasonCode extension, which RFC 5280 §5.3.1 says should be absent. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

PKCS_RSA_PSS_SHA256 has been pub(crate) and excluded from SignatureAlgorithm::iter() (and therefore from_oid) since its introduction, so it is unreachable by users. Its encoding was also doubly wrong: it wrote saltLength 20 explicitly even though RFC 4055 declares saltLength [2] INTEGER DEFAULT 20 (the same X.690 §11.5 violation as the explicit cA FALSE bug), and the declared 20-byte salt did not match the 32-byte salt ring/aws-lc-rs actually use for RSA_PSS_SHA256 signatures. Remove the algorithm, its RsaPss params writer, the key pair loading branches, the id-RSASSA-PSS OID constant, and the commented-out references, rather than shipping latent bugs. PSS support can be reintroduced properly if there is demand. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cpu · 2026-08-11T13:38:19Z

I'd be in favor of squashing both commits for each fix into one.

Done.

cpu · 2026-08-10T20:37:22Z

I let claude loose to do a review of bugs similar to #444 and it came up with several findings I confirmed myself. As an experiment I let it write the unit tests and fixes and then reviewed them myself to satisfaction. In summary:

We were using the wrong time for CRL InvalidityDate
We allowed an empty CRL distribution points URI list that would produce a misencoding
Cert. params with only key_usages or crl_distribution_points wouldn't produce a cert w/ those extensions
There was a way to write a CRL entry with reasonCode==0, which is invalid
PKCS_RSA_PSS_SHA256 salt encoding was wrong at least two ways

The last commit drops some crate-internal RSASSA-PSS bits rather than try to fix the salt length bugs. I think that's the right call and we can revive it (correctly) in #417 when someone has the time/energy.

I opted for a "write an ignored test that catches the bug and fails without the fix, then write the fix and unignore the test" approach here because I wanted to keep the LLM on the rails. If folks prefer we can squash each of those paired commits into just one. LMK.

djc

Nice, LGTM!

I'd be in favor of squashing both commits for each fix into one.

RFC 5280 §5.3.2 defines the invalidity date CRL entry extension as InvalidityDate ::= GeneralizedTime, not the Time CHOICE used for validity and revocation dates. Using write_dt_utc_or_generalized meant any invalidity date between 1950 and 2049 was encoded with a UTCTime tag, producing an invalid extension that strict parsers reject. Write the date as GeneralizedTime unconditionally and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Serializing a CrlDistributionPoint with no URIs produced an empty fullName GeneralNames, violating GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName (RFC 5280 §4.2.1.13). Return the new Error::EmptyCrlDistributionPointUris from certificate and CRL serialization instead of emitting invalid DER, and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Add key_usages and crl_distribution_points to the should_write_exts gate in serialize_der_with_signer. Previously a certificate whose params requested only one of those extensions was silently issued with no extensions at all, because the gate predicted emptiness from a different set of fields than write_extensions actually writes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Filter Unspecified out of the reason code once, before both the presence check and the extension write, instead of applying the filter only in the presence check. Previously reason_code: Some(Unspecified) combined with an invalidity date wrote an ENUMERATED 0 reasonCode extension, which RFC 5280 §5.3.1 says should be absent. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

PKCS_RSA_PSS_SHA256 has been pub(crate) and excluded from SignatureAlgorithm::iter() (and therefore from_oid) since its introduction, so it is unreachable by users. Its encoding was also doubly wrong: it wrote saltLength 20 explicitly even though RFC 4055 declares saltLength [2] INTEGER DEFAULT 20 (the same X.690 §11.5 violation as the explicit cA FALSE bug), and the declared 20-byte salt did not match the 32-byte salt ring/aws-lc-rs actually use for RSA_PSS_SHA256 signatures. Remove the algorithm, its RsaPss params writer, the key pair loading branches, the id-RSASSA-PSS OID constant, and the commented-out references, rather than shipping latent bugs. PSS support can be reintroduced properly if there is demand. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cpu · 2026-08-11T13:38:19Z

I'd be in favor of squashing both commits for each fix into one.

Done.

cpu · 2026-08-10T20:37:22Z

I let claude loose to do a review of bugs similar to #444 and it came up with several findings I confirmed myself. As an experiment I let it write the unit tests and fixes and then reviewed them myself to satisfaction. In summary:

We were using the wrong time for CRL InvalidityDate
We allowed an empty CRL distribution points URI list that would produce a misencoding
Cert. params with only key_usages or crl_distribution_points wouldn't produce a cert w/ those extensions
There was a way to write a CRL entry with reasonCode==0, which is invalid
PKCS_RSA_PSS_SHA256 salt encoding was wrong at least two ways

The last commit drops some crate-internal RSASSA-PSS bits rather than try to fix the salt length bugs. I think that's the right call and we can revive it (correctly) in #417 when someone has the time/energy.

I opted for a "write an ignored test that catches the bug and fails without the fix, then write the fix and unignore the test" approach here because I wanted to keep the LLM on the rails. If folks prefer we can squash each of those paired commits into just one. LMK.

djc

Nice, LGTM!

I'd be in favor of squashing both commits for each fix into one.

RFC 5280 §5.3.2 defines the invalidity date CRL entry extension as InvalidityDate ::= GeneralizedTime, not the Time CHOICE used for validity and revocation dates. Using write_dt_utc_or_generalized meant any invalidity date between 1950 and 2049 was encoded with a UTCTime tag, producing an invalid extension that strict parsers reject. Write the date as GeneralizedTime unconditionally and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Serializing a CrlDistributionPoint with no URIs produced an empty fullName GeneralNames, violating GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName (RFC 5280 §4.2.1.13). Return the new Error::EmptyCrlDistributionPointUris from certificate and CRL serialization instead of emitting invalid DER, and test the results match expected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Add key_usages and crl_distribution_points to the should_write_exts gate in serialize_der_with_signer. Previously a certificate whose params requested only one of those extensions was silently issued with no extensions at all, because the gate predicted emptiness from a different set of fields than write_extensions actually writes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Filter Unspecified out of the reason code once, before both the presence check and the extension write, instead of applying the filter only in the presence check. Previously reason_code: Some(Unspecified) combined with an invalidity date wrote an ENUMERATED 0 reasonCode extension, which RFC 5280 §5.3.1 says should be absent. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

PKCS_RSA_PSS_SHA256 has been pub(crate) and excluded from SignatureAlgorithm::iter() (and therefore from_oid) since its introduction, so it is unreachable by users. Its encoding was also doubly wrong: it wrote saltLength 20 explicitly even though RFC 4055 declares saltLength [2] INTEGER DEFAULT 20 (the same X.690 §11.5 violation as the explicit cA FALSE bug), and the declared 20-byte salt did not match the 32-byte salt ring/aws-lc-rs actually use for RSA_PSS_SHA256 signatures. Remove the algorithm, its RsaPss params writer, the key pair loading branches, the id-RSASSA-PSS OID constant, and the commented-out references, rather than shipping latent bugs. PSS support can be reintroduced properly if there is demand. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cpu · 2026-08-11T13:38:19Z

I'd be in favor of squashing both commits for each fix into one.

Done.

cpu self-assigned this Aug 10, 2026

cpu commented Aug 10, 2026
View reviewed changes

Comment threadrcgen/src/certificate.rs

djc approved these changes Aug 11, 2026
View reviewed changes

cpuand others added 5 commits August 11, 2026 09:21

cpu force-pushed the ci/cpu-bugfixes branch from e14bcee to f8ef6eeCompare August 11, 2026 13:22

cpu enabled auto-merge August 11, 2026 13:38

cpu added this pull request to the merge queue Aug 11, 2026

cpu mentioned this pull request Aug 11, 2026
Added support for RSASSA-PSS padding algorithms #417
Draft

Merged via the queue into rustls:main with commit e2dba45Aug 11, 2026
17 checks passed

cpu deleted the ci/cpu-bugfixes branch August 11, 2026 13:58

cpu self-assigned this Aug 10, 2026

cpu commented Aug 10, 2026
View reviewed changes

Comment threadrcgen/src/certificate.rs

djc approved these changes Aug 11, 2026
View reviewed changes

cpuand others added 5 commits August 11, 2026 09:21

cpu force-pushed the ci/cpu-bugfixes branch from e14bcee to f8ef6eeCompare August 11, 2026 13:22

cpu enabled auto-merge August 11, 2026 13:38

cpu added this pull request to the merge queue Aug 11, 2026

cpu mentioned this pull request Aug 11, 2026
Added support for RSASSA-PSS padding algorithms #417
Draft

Merged via the queue into rustls:main with commit e2dba45Aug 11, 2026
17 checks passed

cpu deleted the ci/cpu-bugfixes branch August 11, 2026 13:58

cpu self-assigned this Aug 10, 2026

cpu commented Aug 10, 2026
View reviewed changes

Comment threadrcgen/src/certificate.rs

djc approved these changes Aug 11, 2026
View reviewed changes

cpuand others added 5 commits August 11, 2026 09:21

cpu force-pushed the ci/cpu-bugfixes branch from e14bcee to f8ef6eeCompare August 11, 2026 13:22

cpu enabled auto-merge August 11, 2026 13:38

cpu added this pull request to the merge queue Aug 11, 2026

cpu mentioned this pull request Aug 11, 2026
Added support for RSASSA-PSS padding algorithms #417
Draft

Merged via the queue into rustls:main with commit e2dba45Aug 11, 2026
17 checks passed

cpu deleted the ci/cpu-bugfixes branch August 11, 2026 13:58

cpu self-assigned this Aug 10, 2026

cpu commented Aug 10, 2026
View reviewed changes

Comment threadrcgen/src/certificate.rs

djc approved these changes Aug 11, 2026
View reviewed changes

cpuand others added 5 commits August 11, 2026 09:21

cpu force-pushed the ci/cpu-bugfixes branch from e14bcee to f8ef6eeCompare August 11, 2026 13:22

cpu enabled auto-merge August 11, 2026 13:38

cpu added this pull request to the merge queue Aug 11, 2026

cpu mentioned this pull request Aug 11, 2026
Added support for RSASSA-PSS padding algorithms #417
Draft

Merged via the queue into rustls:main with commit e2dba45Aug 11, 2026
17 checks passed

cpu deleted the ci/cpu-bugfixes branch August 11, 2026 13:58

cpu self-assigned this Aug 10, 2026

cpu commented Aug 10, 2026
View reviewed changes

Comment threadrcgen/src/certificate.rs

djc approved these changes Aug 11, 2026
View reviewed changes

cpuand others added 5 commits August 11, 2026 09:21

cpu force-pushed the ci/cpu-bugfixes branch from e14bcee to f8ef6eeCompare August 11, 2026 13:22

cpu enabled auto-merge August 11, 2026 13:38

cpu added this pull request to the merge queue Aug 11, 2026

cpu mentioned this pull request Aug 11, 2026
Added support for RSASSA-PSS padding algorithms #417
Draft

Merged via the queue into rustls:main with commit e2dba45Aug 11, 2026
17 checks passed

cpu deleted the ci/cpu-bugfixes branch August 11, 2026 13:58

cpu self-assigned this Aug 10, 2026

cpu commented Aug 10, 2026
View reviewed changes

Comment threadrcgen/src/certificate.rs

djc approved these changes Aug 11, 2026
View reviewed changes

cpuand others added 5 commits August 11, 2026 09:21

cpu force-pushed the ci/cpu-bugfixes branch from e14bcee to f8ef6eeCompare August 11, 2026 13:22

cpu enabled auto-merge August 11, 2026 13:38

cpu added this pull request to the merge queue Aug 11, 2026

cpu mentioned this pull request Aug 11, 2026
Added support for RSASSA-PSS padding algorithms #417
Draft

Merged via the queue into rustls:main with commit e2dba45Aug 11, 2026
17 checks passed

cpu deleted the ci/cpu-bugfixes branch August 11, 2026 13:58

cpu self-assigned this Aug 10, 2026

cpu commented Aug 10, 2026
View reviewed changes

Comment threadrcgen/src/certificate.rs

djc approved these changes Aug 11, 2026
View reviewed changes

cpuand others added 5 commits August 11, 2026 09:21

cpu force-pushed the ci/cpu-bugfixes branch from e14bcee to f8ef6eeCompare August 11, 2026 13:22

cpu enabled auto-merge August 11, 2026 13:38

cpu added this pull request to the merge queue Aug 11, 2026

cpu mentioned this pull request Aug 11, 2026
Added support for RSASSA-PSS padding algorithms #417
Draft

Merged via the queue into rustls:main with commit e2dba45Aug 11, 2026
17 checks passed

cpu deleted the ci/cpu-bugfixes branch August 11, 2026 13:58

cpu self-assigned this Aug 10, 2026

cpu commented Aug 10, 2026
View reviewed changes

Comment threadrcgen/src/certificate.rs

djc approved these changes Aug 11, 2026
View reviewed changes

cpuand others added 5 commits August 11, 2026 09:21

cpu force-pushed the ci/cpu-bugfixes branch from e14bcee to f8ef6eeCompare August 11, 2026 13:22

cpu enabled auto-merge August 11, 2026 13:38

cpu added this pull request to the merge queue Aug 11, 2026

cpu mentioned this pull request Aug 11, 2026
Added support for RSASSA-PSS padding algorithms #417
Draft

Merged via the queue into rustls:main with commit e2dba45Aug 11, 2026
17 checks passed

cpu deleted the ci/cpu-bugfixes branch August 11, 2026 13:58

Uh oh!

Conversation

cpu commented Aug 10, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

djc left a comment

Choose a reason for hiding this comment

Uh oh!

cpu commented Aug 11, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

cpu commented Aug 10, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

djc left a comment

Choose a reason for hiding this comment

Uh oh!

cpu commented Aug 11, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

cpu commented Aug 10, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

djc left a comment

Choose a reason for hiding this comment

Uh oh!

cpu commented Aug 11, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

cpu commented Aug 10, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

djc left a comment

Choose a reason for hiding this comment

Uh oh!

cpu commented Aug 11, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

cpu commented Aug 10, 2026•
edited
Loading

cpu commented Aug 10, 2026•
edited
Loading

cpu commented Aug 10, 2026•
edited
Loading

cpu commented Aug 10, 2026•
edited
Loading

cpu commented Aug 10, 2026•
edited
Loading

cpu commented Aug 10, 2026•
edited
Loading