Subject emailAddress isn't checked against rfc822Name constraints when the leaf has no subjectAltName
まだ誰も着手していません。
評価
調査の方向性
Start with check_name_constraints in src/subject_name/mod.rs, which checks SAN entries and the subject directory name but never extracts the subject emailAddress when there is no subjectAltName. Run the linked gist repro (cargo run) to see forbidden_no_san accepted while forbidden_email_san is rejected, and compare with the openssl verify control. Done means the no-SAN case is rejected under a permitted rfc822Name constraint, with the RFC 5280 section 4.2.1.10 behaviour and related issues #445 and #70 taken into account.
索引モデルが issue の本文から書いたものです。
説明
Re-filing from GHSA-hc65-xjvf-77jj as asked.
rustls-webpki 0.103.16 (and main) accepts a certificate whose subject emailAddress is outside its issuer's permitted rfc822Name subtree when the leaf has no subjectAltName. If the same email is in a SAN, the constraint fails closed as expected.
As @ctz pointed out on the advisory, webpki has no API for asserting email identities and ignores names in the subject. So the impact is narrow: webpki accepts a constrained chain that isn't valid under its constraints. It only matters if something else extracts the subject email from a chain webpki has validated.
Details
RFC 5280 section 4.2.1.10 applies rfc822Name constraints to an email address in the subject DN when there's no subjectAltName. check_name_constraints checks the SAN entries plus the subject as a directory name. A directory name doesn't match an rfc822Name subtree, so it's skipped, and the subject emailAddress is never pulled out.
An email SAN under an email constraint hits the unsupported-name path and is rejected. The no-SAN subject email never reaches that path.
Related: #445 (email constraint support) and #70 (RFC 5280 deviations).
Repro
https://gist.github.com/DicksonWu654/7cb644c9485e48118a11899867fee090
cargo run builds against rustls-webpki = "=0.103.16" with the certs embedded. A root signs an intermediate with a critical permitted rfc822Name subtree for allowed.test, which signs three client-auth leaves:
allowed_no_san: accepted
forbidden_no_san: accepted
forbidden_email_san: rejected (NameConstraintViolation)
forbidden_no_san has emailAddress = [email protected] in the subject and no SAN. openssl verify on the same chain fails with error 47 (permitted subtree violation). The README has a one-liner for that.
Possible fix
When the leaf has no subjectAltName, treat subject emailAddress attributes like SAN emails for constraint purposes. With the current fail-closed handling, that means rejecting the chain when an email constraint is present.
I used AI tools (OpenAI Codex and Anthropic Claude) to find this, build the test and draft the report. The test and the OpenSSL control were re-run against 0.103.16 before the original report, and the cited code was checked against source.
- 主要言語
- Rust
- スター
- 167
- フォーク
- 112
- 平均マージ
- 4時間 28分
- マージ済み PR（30日）
- 4
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
rustls/webpki のほかの issue
-
Path building re-parses every intermediate on each budgeted call (unbudgeted CPU cost)対応中かも @batmnnn が 23 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
-
Improve error message when denying subject name due to wildcard in public suffix再び着手できるかも @ctz が 80 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
-
Consider all candidate CRLs再び着手できるかも @cpu が 85 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
-
Add opt-in support for ignoring URI name constraints対応中かも @djc が 135 日前に担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
pop-os/cosmic-settings#2296 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
jonathanong/no-mistakes#3431 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
Ephemeral-AI-Lab/layerfs#689 ·
メンテナーはふだん 1 日以内に返信