IssuingDistributionPoint has the wrong AssociatedOid (id-pe-subjectInfoAccess)
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 86/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- cryptography
Research direction
Start in x509-cert/src/ext/pkix/crl/dp.rs and compare IssuingDistributionPoint's AssociatedOid with const_oid::db::rfc5280. Run or add the two regression tests in tests/crl.rs: one for the constant and one for lookup of a wire-encoded IDP by associated OID. Done means both pass and the relevant suite remains unchanged apart from the fix.
Written by the indexing model from the issue text.
Description
x509-cert/src/ext/pkix/crl/dp.rs:
impl AssociatedOid for IssuingDistributionPoint {
const OID: ObjectIdentifier = ID_PE_SUBJECT_INFO_ACCESS; // 1.3.6.1.5.5.7.1.11
}
issuingDistributionPoint is 2.5.29.28 (RFC 5280 §5.2.5). 1.3.6.1.5.5.7.1.11 is id-pe-subjectInfoAccess, which ext/pkix/access.rs already binds to SubjectInfoAccessSyntax.
So a lookup by associated OID never finds an IDP. It searches for 1.3.6.1.5.5.7.1.11 while the CRL carries 2.5.29.28, and comes back with "no such extension" rather than an error. If you're reading indirect_crl to decide whether a CRL's entries apply to your own issuer's serial space, you'll treat an indirect CRL as a direct one.
impl_extension!(IssuingDistributionPoint, critical = true) uses the same constant, so the encode side writes the wrong OID too.
Present in 0.3.0 and on master at b1e1582.
Repro
use const_oid::{AssociatedOid, db::rfc5280::ID_CE_ISSUING_DISTRIBUTION_POINT};
use x509_cert::ext::pkix::IssuingDistributionPoint;
assert_eq!(IssuingDistributionPoint::OID, ID_CE_ISSUING_DISTRIBUTION_POINT); // fails
Fix
- const OID: ObjectIdentifier = ID_PE_SUBJECT_INFO_ACCESS;
+ const OID: ObjectIdentifier = ID_CE_ISSUING_DISTRIBUTION_POINT;
ID_CE_ISSUING_DISTRIBUTION_POINT is already in const_oid::db::rfc5280.
I have this locally with two regression tests in tests/crl.rs, one for the constant and one that puts a real IDP on the wire and finds it by associated OID. Both fail before, pass after, and the rest of the suite is unchanged (78 tests plus 10 doc-tests). The 5 failures in tests/builder.rs are zlint: command not found and happen on unmodified master too.
It's a behaviour change for anyone already working around it, so probably wants a CHANGELOG entry. Happy to send a PR.
- Dominant language
- Rust
- Stars
- 338
- Forks
- 188
- Avg merge
- 4d 6h
- Merged PRs (30d)
- 15
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from RustCrypto/formats
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
RustCrypto/formats#2366 ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
RustCrypto/formats#2430 · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
RustCrypto/formats#2428 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
RustCrypto/formats#2427 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
RustCrypto/formats#2403 · 2 comments ·
All issues in RustCrypto/formats
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100