Fix DecodeSubjInfoAcc rejecting certs without id-ad-caRepository#9917
Open
jayharper wants to merge 1 commit intowolfSSL:masterfrom
Open
Fix DecodeSubjInfoAcc rejecting certs without id-ad-caRepository#9917jayharper wants to merge 1 commit intowolfSSL:masterfrom
jayharper wants to merge 1 commit intowolfSSL:masterfrom
Conversation
DecodeSubjInfoAcc() returns ASN_PARSE_E when the Subject Information Access extension does not contain an id-ad-caRepository access description. This is overly strict: RFC 5280 section 4.2.2.2 defines SIA as a SEQUENCE OF AccessDescription where each entry may use any access method OID — id-ad-caRepository is only one possibility. Real-world impact: ISO 15118-20 (Electric Vehicle charging) PKI certificates include SIA extensions with custom access-method OIDs (e.g. under arc 2.40.246.14.20.0). wolfSSL rejects these otherwise valid certificates with ASN_PARSE_E, preventing interoperability with ISO 15118-20 Plug & Charge infrastructure. Change: when no caRepository URI is found in the SIA extension, log a debug message but do not set ret = ASN_PARSE_E. The extension is still fully parsed; only the hard failure is removed. Signed-off-by: Claude Opus 4.6 <noreply@anthropic.com>
|
Can one of the admins verify this patch? |
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
2 participants
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.
Summary
DecodeSubjInfoAcc()currently returnsASN_PARSE_Ewhen the Subject Information Access (SIA) extension does not contain anid-ad-caRepository(OID 1.3.6.1.5.5.7.48.5) access description. This is overly strict.RFC 5280 section 4.2.2.2 defines SIA as a
SEQUENCE OF AccessDescriptionwhere each entry may use any access method OID —id-ad-caRepositoryis only one possibility. The existing code references the Federal PKIfpki-x509-cert-profile-commonprofile (section 5.3) which does requirecaRepository, but this is a profile-specific constraint, not an RFC 5280 requirement.Real-world impact
ISO 15118-20 (Electric Vehicle charging) PKI certificates include SIA extensions with custom access-method OIDs defined under arc
2.40.246.14.20.0(ISO/IEC 15118-20 Plug & Charge). These certificates are structurally valid per RFC 5280 but are rejected by wolfSSL withASN_PARSE_E, preventing interoperability with ISO 15118-20 charging infrastructure.This was discovered and validated on production EV charging equipment (SECC) parsing contract certificate chains from Keysight EV simulators.
Change
When no
caRepositoryURI is found in the SIA extension, log a debug message viaWOLFSSL_MSG()but do not setret = ASN_PARSE_E. The extension is still fully parsed and anycaRepositoryentries that are present are still extracted — only the hard failure for missing entries is removed.Test plan
ASN_PARSE_Efor missingcaRepository)id-ad-caRepositoryin SIA continue to work identically