Skip to content

Add intermediate certificates to auth token model#123

Draft
aarmam wants to merge 13 commits into
web-eid-mobilefrom
NFC-128
Draft

Add intermediate certificates to auth token model#123
aarmam wants to merge 13 commits into
web-eid-mobilefrom
NFC-128

Conversation

@aarmam

@aarmam aarmam commented Jun 30, 2026

Copy link
Copy Markdown

Signed-off-by: Mart Aarma mart.aarma@nortal.com

@aarmam aarmam requested a review from mrts June 30, 2026 11:03
@aarmam aarmam force-pushed the NFC-128 branch 4 times, most recently from b78e560 to 0a16568 Compare July 1, 2026 06:50
@aarmam aarmam marked this pull request as draft July 2, 2026 10:44
aarmam added 4 commits July 3, 2026 15:11
Once intermediate certificates can sit between the leaf and the trust
anchor, the OCSP CertificateID must be built from the certificate that
directly issued the subject, and RFC 6960 responder authorization must
reference the same certificate. Return the direct issuer from the built
certification path; when the path has a single certificate, the trust
anchor is the direct issuer. Behavior is unchanged for configurations
where every configured CA is a trust anchor.
…-path validation

The shared certification-path validation labeled every leaf validity
failure as a user-certificate failure, so the AIA OCSP responder flow
had to duplicate the validity check beforehand to get a correctly
attributed message. Let callers name the certificate role and drop the
duplicate responder pre-check; validity is still checked first, inside
the shared method.
…rtificates

Web eID 1.1 tokens may carry the intermediate CA certificates of the
certificate chain. Accept them in certification-path validation as
untrusted path candidates only: the path must still terminate at a
configured trust anchor. No caller passes token data yet.
@aarmam aarmam force-pushed the NFC-128 branch 3 times, most recently from 4466472 to dee60b3 Compare July 3, 2026 13:13
aarmam added 3 commits July 3, 2026 17:19
…rtificates

Token-supplied intermediates are attacker-controlled input, so a
revoked intermediate must not become part of a trusted certification
path. Check the CA suffix of the built path (the leaf's role-specific
revocation policy stays with the caller) with the platform JCA
PKIXRevocationChecker, which prefers OCSP and falls back to CRLs;
SOFT_FAIL is deliberately not enabled. Revocation checking is an
explicit caller choice: the authentication and signing certificate
paths enable it, the AIA OCSP responder path does not, per RFC 6960
section 4.2.2.2.1 id-pkix-ocsp-nocheck semantics and because checking
the responder's own chain via OCSP would be circular.

The platform checker is used instead of the application OcspClient
because intermediate CAs commonly publish CRLs without OCSP AIA
records, the OcspClient freshness policy (nonce, time skew, thisUpdate
age) encodes end-entity assumptions that are wrong for CA-tier data,
and the WE2-1030 platform-OCSP refactor removes the OcspClient from
core validation, so platform-based checking ports forward as a block.

A revocation failure names the offending intermediate certificate
instead of the validated leaf.
@sonarqubecloud

sonarqubecloud Bot commented Jul 3, 2026

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant