eMudhraの中間CA秘密鍵の危殆化
- カテゴリ
- 設定不備・誤公開
Mozillaの2026年10月20日の発表によると、インドの認証局eMudhraの中間CA証明書8件に関連する秘密鍵が危殆化し、攻撃者が管理していないサイトの偽のHTTPS証明書を発行できるおそれがあった［6］。Mozillaの調査では、秘密鍵はすべて256未満の整数で、ほぼ即座に復元できた［8］。eMudhraは10月22日、グローバルのSSL/TLS証明書事業から自主的に撤退すると発表した［3］。
経緯
eMudhraがインドの証券取引所に出した声明では、問題の中間CAはGlobal TLS事業で信頼されていた中間CAの一部で、ECCのルートの下に作られた［2］。作成の場になった鍵生成セレモニー（KGC）では、FIPS 140-2 Level 3のHSMを使った［2］。KGCの欠陥のため、鍵のラップ／アンラップの段階で元の強い鍵と並んで弱い鍵の2組目ができ、ブラウザのルートストアに公開されたのは弱い鍵だった［1、2］。ステータスページでは、HSMを使わなかったという指摘を誤りとした［1］。
報告者がMozillaのバグ管理システムBugzillaのBug 2083449に載せた経過によると、CCADBの証明書の試験用のコーパスでEC鍵の破綻を見つけ、続く全件の確認でSectigoのクロス署名も影響を受けると分かった［8］。Mozillaに届いた報告はChrome Root Programが転送したもので、すべての鍵を保有している証明が付いていた［8］。Mozillaは報告者の手法を知らないまま独自に秘密鍵を復元し、鍵生成の欠陥と悪用の容易さを確かめた［8］。
Mozillaの10月18日の予備的な調査では、影響を受けた鍵は24件の中間CAの一群に由来する［8］。2025年4月30日に作られたこの一群は、A・B・Cの3系列、RSA4096とP384の2方式、DV・OV・EV・CSの4用途に分かれ、影響を受けたのはB系列とC系列のP384の鍵すべてだった［8］。A系列は2025年5月に失効し、A-1系列に置き換わっていた［8］。A系列とA-1系列のP384の鍵は、さらに相当の労力をかけても復元できず、RSAの鍵はまだ調べていないとした［8］。
Mozillaによると、秘密鍵は最後の1バイトを除いて実質ゼロで、baby-step giant-step法でも、最初の256個のP384鍵を作るだけでも復元できる［8］。手元のAIエージェントも、簡単な指示で1回目に秘密鍵を復元した［8］。Googleは、これらの秘密鍵は不十分な乱数で生成されていたと説明した［11］。
eMudhraの担当者は10月19日のBugzillaへの投稿で、そのKGCでECCの発行CAを作るのに使ったスクリプトに欠陥があったようだとする予備的な評価を示し、経過を順に挙げた［8］。
- 元のECC鍵は、想定どおりHSMの中で作られた［8］。
- 鍵を輸出する予定だったため、ラップ／アンラップを試す、承認済みの手順の逸脱を入れた［8］。
- コードの欠陥で、より弱い2組目の鍵がHSMの中に作られた［8］。
- 鍵のラベルが似ていたため、弱い鍵を誤って証明書署名要求（CSR）の作成に使い、ルートで署名した［8］。
- 弱い鍵のCSRは、クロス署名のためにSectigoにも送った［8］。
同じ日の投稿では、装置に原因があるようには見えないとし、RSAの発行CAは別の経路で作ったため影響を受けないと説明した［8］。同様の他の発行CAが影響を受けないことは主にAIを使った数学的なモデルで確かめ、他のCAは別の製造元（EntrustとCrypto4A）のHSMで作っており、発行は止めない［8］。このKGCでは複数の段階に人為的なミスがあったとし、今後1週間で過去のすべての鍵生成セレモニーを検証し直すとした［8］。
Bug 1970728との関係
Mozillaは、影響を受けたTLS用の中間CA6件では、2025年にもeMudhraが不正な署名のCRLを作っていたと指摘した［8］。そのBug 1970728では、UTCで2025年5月29日9時46分から6月6日7時30分まで、不正な署名のCRLが公開されていた［9］。eMudhraは原因を手作業でCRLを作ったときの誤った鍵の設定とし、各中間CAの適切な秘密鍵でCRLを作り直した［9］。
eMudhraの担当者の2026年10月19日の投稿では、2025年のCRLは本来の鍵で署名したものの署名が不正になったため、欠陥のある鍵で署名し直したとした［8］。Chrome Root Programは、eMudhraがBug 1970728で鍵ペアが2組あったことを報告しなかった点に、透明性とインシデント対応への深刻な懸念を示し、Q1〜Q12の質問を出した［8］。
時系列
| 日付 | 主体 | 内容 | 資料 |
|---|---|---|---|
| 2025年 | eMudhra | 鍵生成セレモニーで、影響を受けた中間CAを作った | ［1］ |
| 2026年 | 報告者 | 18時5分（UTC）、Apple、Chrome、Microsoft、Mozilla、eMudhraに報告と証明をメールで送った | ［8］ |
| 2026年 | 19時45分（UTC）、CRLSetの更新で影響を受けた中間CAのSPKIハッシュを遮断した | ［11］ | |
| 2026年 | Mozilla | 20時6分（UTC）に報告を受け、22時59分（UTC）までにOneCRLでの遮断を標準設定のFirefoxへ配信し終えた | ［6］ |
| 2026年 | eMudhra | 21時29分（UTC）、受領を伝え、一部にクロス署名したSectigoに通知したと報告した | ［8］ |
| 2026年 | eMudhra | 9時24分〜9時38分（UTC）、影響を受けた中間CAをすべて失効させた〔注1〕 | ［1、8］ |
| 2026年 | Apple | TLS用の中間CAの証明書12件をApple製品で遮断し始めた〔注2〕 | ［12］ |
| 2026年 | Sectigo | クロス署名したCA証明書の失効を終えた | ［8］ |
| 2026年 | 22時（UTC）ごろ、Google Play開発者サービスでAndroid端末とGooglebookに同等の更新を届けた | ［11］ | |
| 2026年 | Mozilla | dev-security-policyで公表し、emSign ECC Root CA - G3の信頼を緊急に取り消すと決めた | ［8、10］ |
| 2026年 | emSign ECC Root CA - G3をChrome Root Storeから外したと公表した | ［11］ | |
| 2026年 | eMudhra | ステータスページで最初の告知を出し、emSign ECC Root CA - G3につながるすべての中間CAからの発行を止めた | ［1、8］ |
| 2026年 | eMudhra | BSEとNSEに声明を提出した | ［2］ |
| 2026年 | CERT-In | 勧告CIAD-2026-0050を出した | ［20］ |
| 2026年 | Apple | emSign ECC Root CA - G3の遮断も始めた | ［12］ |
影響範囲
| 中間CA | 用途 | 秘密鍵の値（Scott Helmeの計算） | 資料 |
|---|---|---|---|
| EM DV TLS CA - G3B | TLS | 156 | ［8、23］ |
| EM OV TLS CA - G3B | TLS | 155 | ［8、23］ |
| EM EV TLS CA - G3B | TLS | 115 | ［8、23］ |
| EM DV TLS CA - G3C | TLS | 230 | ［8、23］ |
| EM OV TLS CA - G3C | TLS | 4 | ［8、23］ |
| EM EV TLS CA - G3C | TLS | 56 | ［8、23］ |
| EM OV CS CA - G3B | コード署名 | 66 | ［8、23］ |
| EM OV CS CA - G3C | コード署名 | 237 | ［8、23］ |
Mozillaの記録では、G3BはeMudhra BV、G3CはeMudhra Incの名義だった［8］。TLS用はChrome・Mozilla・Microsoft・Appleのルートプログラムが、コード署名用はMicrosoftが信頼していた［8］。情報サイトemudhra.we-have-a-problem.comの一覧のJSONでは、eMudhraの発行分の有効期限は2040年4月28日だった［22］。それぞれに、SectigoのAAA Certificate Servicesによるクロス署名の証明書があった［22］。
eMudhraのステータスページは、影響を受けた中間CAは1件を除いて本番に配備しておらず、本番の1件を含めてエンドエンティティ証明書を発行していないと説明した［1］。インシデントはこれらの中間CAに限られ、ルートCAの秘密鍵や他の中間CAには及ばない［1］。ルートの信頼の取り消しは予防の措置で、eMudhraの知る限り、欠陥のある手順で作った他のルートや中間CAは無いとした［1］。本番に入れていたのはEM DV TLS CA - G3Cで、eMudhraは報告の受領の連絡で停止したと伝えた［8］。
取引所への声明では、インフラは侵害されず、データの侵害も無く、物理的・論理的なセキュリティ管理はすべて保たれていた［2］。Global TLS事業は、インドの電子署名証明書（DSC）とeSignの事業とは完全に別の基盤で動いている［2］。この事業は売上の約1%だが、数値で示せない評判上のリスクがありうるとした［2］。ステータスページでも、インド内外の電子署名とeSign、emSigner、CertiNext、emCA、Privatrust、SecurePassには影響が無いとした［1］。
eMudhraは、公表前に誰かが弱い鍵を復元・悪用した証拠は把握していないと説明した［1］。Googleの説明では、遮断の前にこれらのTLS用の中間CAにつながる証明書はCT（Certificate Transparency）のログに記録されておらず、CTを強制するChromeなどのクライアントに対して不正な証明書は使われえなかった［11］。Cloudflareのセキュリティの審査では、自社のサービスでの実際の悪用は見つかっていない［17］。
ステータスページによると、影響は信頼を取り消されたECCのルートにつながるTLS証明書に限られ、米国の単一の顧客エコシステムの中に収まる［1］。発行済みのTLS証明書の大半は、他の階層につながっていて影響を受けない［1］。
| 区分 | 件数 | 示した組織 | 資料 |
|---|---|---|---|
| 移行が要る証明書（10月20日の初期の見込み） | 約30,000件（約97%がACME経由） | eMudhra | ［8］ |
| 有効期限内のプレ証明書（10月21日のCTのデータ） | 約30,800件 | Chrome Root Program | ［8］ |
| そのうちInternet2／InCommonの下位CA2件の発行 | 30,791件（99.9%） | Chrome Root Program | ［8］ |
| そのうちInCommon Intermediate CA - OVG3Cの発行 | 23,806件 | Chrome Root Program | ［8］ |
| そのうちInCommon Intermediate CA - DVG3Cの発行 | 6,985件 | Chrome Root Program | ［8］ |
| そのうちeMudhra自身の中間CAの発行 | 18件 | Chrome Root Program | ［8］ |
コーネル大学は10月21日、一部のサイトがGoogleとMozillaのブラウザでエラーになると告知し、InCommonのOVG3Cの中間CAから出たECCの証明書をRSAで申請し直すよう案内した［18］。10月22日には、大半のSSL証明書を再発行したとして告知を閉じた［18］。The Hacker Newsの10月22日の記事によると、InCommonは2026年4月〜7月に証明書のサービスをeMudhraのCertiNextの基盤に移していた［25］。ミシガン大学のSafe Computingも、『Root Certificate Authorities Distrusted』と題した告知を出した［19］。
対応と現状
ルートプログラムの遮断
Mozillaは10月20日のブログで、設定のためにOneCRLの更新を受け取れなかった可能性のある少数の利用者に向けて、Firefox 158.0.1、ESR 115.43.1、ESR 153.5.1を公開したと説明した［6］。NSS 3.131.1では、影響を受けた中間CAに署名したルート証明書を信頼リストから外す［6］。MFSA 2026-111では、この件をCVE-2026-113470（影響度high）とした［7］。
Mozillaの10月20日のBugzillaへの投稿では、複数の人物が独自に秘密鍵を復元し、一部が公表したことを把握したとした［8］。eMudhraには、emSign ECC Root CA - G3につながるすべての中間CAからの発行を止め、加入者を移すよう求めた［8］。emSign Root CA - G1の信頼は、現段階では取り消さないとした［8］。
dev-security-policyでMozillaは、失効情報を確実に確かめ、無ければ拒否するクライアントなら対応は要らないと、トラストストアの運営者に伝えた［10］。中間CAを個別に遮断できればimpacted-intermediates.jsonの証明書を遮断し、できなければ、中間CAに署名した上位のルートの信頼を取り消すかを検討するよう勧めた［10］。
Googleのブログでは、emSign ECC Root CA - G3のChrome Root Storeからの削除は、10月27日火曜の朝（太平洋夏時間）にChrome Root Storeを使うすべての端末へ届く予定だ［11］。このルートにつながる正規の証明書の一部も、Chromeで使えなくなる［11］。Googleはサイトの運営者に、別のPKIの階層から直ちに新しいTLS証明書を取得して導入するよう求めた［11］。ルートストアの他の鍵に同じ弱いエントロピーの問題が無いことを確かめ、CTのログがこれらのCAにつながる証明書を拒むよう更新されることにも取り組んだ［11］。
Chrome Root Programはdev-security-policyで、CRLSetでのSPKIハッシュの遮断は、同じ鍵を持つSectigoのクロス証明書も防いだと説明した［10］。コード署名用の中間CAはTLSの経路に使えないため、遮断は要らなかった［10］。Sectigoは、クロス署名の上位にあるSectigoが運営するルートは、ChromeとMozillaのルートストアから以前に外れているが、MicrosoftとAppleでは信頼が残ると説明した［8］。
Appleのサポート文書では、遮断は設定データの自動配信で届き、ソフトウェアの更新は要らない［12］。コード署名用の中間CAは、Appleのフレームワークが信頼していない［12］。macOSやXcode Command Line Toolsに含まれる、curl・git・python3・ruby・perl・opensslを含む一部のコマンドラインツールは、/etc/ssl/cert.pemで証明書を確かめる［12］。
このファイルにあるルートCAにつながる証明書では、これらのツールはAppleの遮断も失効も確かめない［12］。Appleは、このファイルを今後のmacOSの更新で改めるとした［12］。emudhra.we-have-a-problem.comは、MicrosoftがWindowsの証明書信頼リストの自動更新で遮断を配信し、Microsoftの製品では10月20日から遮断していると記した［21］。
下流のソフトウェアの更新
| 組織 | 公開日 | 内容 | 資料 |
|---|---|---|---|
| Goチーム | 2026年10月20日 | Go 1.27.3と1.26.10で、特定のCAの運用上の懸念から少数の中間証明書の信頼を遮断した（CVE-2026-111943） | ［13］ |
| Canonical | 2026年10月20日 | USN-8944-1で、Ubuntuのca-certificatesからemSign ECC Root CA - G3を外した | ［16］ |
| Cloudflare | 2026年10月20日 | Cloudflare One Client・WARP・cloudflaredを更新し、19時20分（UTC）にCDNとサーバー側のZero Trustの緩和策を展開し終えた | ［17］ |
| Python Software Foundation | 2026年10月21日 | Python 3.15.1と3.14.9を前倒しのセキュリティリリース、3.13.17を特別のセキュリティリリースとして公開し、同梱のpip 26.2.2（certifi 2026.10.19を含む）で対処した | ［14］ |
| Red Hat | 2026年10月21日 | RHSB-2026-012（影響度Critical）を出し、RHEL 6〜10とRHEL上の製品が影響を受けるとした | ［15］ |
The Hacker Newsによると、Goのセキュリティチームは10月19日に問題を知り、悪用が容易でその日のうちに公になると見込んで、リリースノートを意図的にあいまいにした［24］。Red Hatは、ソフトウェアの脆弱性ではなく第三者のCAの秘密鍵の危殆化だとし、RHELのca-certificatesの追跡にCVE-2026-114406を割り当てた［15］。
インドの当局の対応
CERT-Inの10月21日の勧告では、秘密鍵の弱さは鍵生成で生じたもので、P-384の暗号方式そのものの脆弱性を示すものではない［20］。10月21日の段階では、引用した公開の情報から鍵の悪用は確かめられていないとし、emSign ECC Root CA - G3の削除で、このルートの正規の証明書が信頼されなくなる可能性を挙げた［20］。電子・情報技術省（MeitY）の下の認証局管理官（CCA）が規制するDSCとeSignは、影響を受けないとした［20］。鍵生成の手順には、鍵パラメータ・鍵識別子・CSRの対応付けの独立した検証と、maker-checkerの統制を組み込むよう勧めた［20］。
ThePrintの10月21日の記事によると、MeitYの幹部は、省としてこの件を重く受け止め、調査のための特別チームを設けたと述べた［26］。幹部は、MeitYはこの事業の監査に関わっていないとも述べた［26］。eMudhraの10月23日の発表では、MeitYは、インドの顧客への影響はごく限られ、eSignatureを含むインドの認証局事業には及んでいないとの見方を示した［5］。
eMudhraの措置と事業撤退
ステータスページの10月21日の更新では、eMudhraは影響を受けた顧客エコシステムに、独立して運営される別の公的に信頼されたCAの階層から新しい証明書を発行している［1］。すべてのEnterprise TLSの顧客に追加のCAの証明書を提供し、原因になったラップ／アンラップの段階から鍵生成セレモニーの全段階を見直している［1］。影響を受けた顧客とパートナーには直接知らせた［1］。10月22日の更新では、すべての顧客にSectigoが発行する証明書を代わりの選択肢として提供し、G1のルート証明書は有効なままで引き続き全面的に支える［1］。
撤退の発表で、eMudhraの会長は、グローバルのSSL/TLSは事業の小さな部分で、データ主権とコンプライアンスの要件で複雑さと費用が増え、一部の大手が無償で発行していることもあって、事業の見込みと投資の効率が下がっていたと述べた［3］。会長は、SNSでの拡散が事業の規模に見合わない注目を招いたとし、取締役会は撤退が正しい判断だと結論したと説明した［3］。
同じ発表では、移行を終えるまではG1のRSAルートで顧客へのサービスを続け、影響を受ける顧客に連絡して、移行の間は提携先の証明書に無償で置き換える［3］。失効と証明書の状態を確かめるサービスは、発行済みのすべての証明書が期限切れか置き換えになるまで動かし、根本原因の完全な報告書を含め、ルートプログラムへの残りの約束も果たす［3］。
eMudhraが10月23日に取引所へ届け出た書面によると、ICRAはこのインシデントの発生と発表に伴って格付を見直した［4］。同じ日のeMudhraの発表では、ICRAはRs 35 croreの未割当枠の格付を[ICRA]A (Stable)/[ICRA]A1に据え置いた［5］。
説明の食い違い
eMudhraは取引所への声明で、ルートと発行CAは2年続けて独立した監査を受けたと説明した［2］。Bugzillaの参加者の指摘では、2回の年次監査が覆うのは、これらの鍵が作られてから2026年5月31日までの約13か月で、2年ではない［8］。
ステータスページでは、研究者はAIを使ったツールの助けで弱い鍵を割り出したと伝えられているとした［1］。報告者がdev-security-policyで示した発見の手段は、google/paranoid_cryptoだった［10］。
eMudhraの担当者は10月23日の投稿で、SNSでの激しい注目と投資家や顧客による分析のため、意味のある分析はほぼできないと述べた［8］。Chrome Root Programは、それらは回答が遅れる理由として受け入れられないとした［8］。Mozillaは、10月20日に送った質問に24時間以内の最初の回答を求めたが、eMudhraは期限の後にさらに24時間を求め、10月23日の投稿までに回答は届いていない［8］。
eMudhraの10月25日の投稿によると、CCADBの規定では完全な報告書の提出期間は14日間で、まだその期間内にある［8］。影響を受けたCAは確認から14時間以内にcACompromiseを理由に失効させたとし、期限内に報告書を出すと書いた［8］。
未公表の事項
- 正確な根本原因と、弱い2組目の鍵を作ったスクリプトの欠陥の中身（eMudhraは、調査を終えたら根本原因を全文公表するとした［1］）
- 公表前の弱い鍵の復元と悪用の有無（emudhra.we-have-a-problem.comは、CTを強制しないクライアントが狙われたかは分からないとした［21］）
- eMudhraが影響を受けたとした米国の顧客エコシステムの名前と、移行を終えた証明書の数
- グローバルのSSL/TLS証明書事業からの撤退の完了日と、置き換えの証明書を出す提携先の名前
- Chrome Root StoreでのeMudhraの残りのCA証明書の扱い（Googleは、含め続けるかを精査しているとした［11］）
注
出典
当事者
- ［1］eMudhra Limited『eMudhra Statement on Recent Certificate Security Incident』（2026年10月20日公開、2026年10月22日更新）
- ［2］eMudhra Limited『eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA』（2026年10月21日公開、PDF、適時開示）
- ［3］eMudhra Limited『eMudhra to Exit global SSL/TLS Certificate Business; Will Sharpen Focus on Core Enterprise Solutions and trust services other than SSL/TLS』（2026年10月22日公開、PDF、適時開示）
- ［4］eMudhra Limited『Intimation under Regulation 30 ‐ Revision in Credit Rating by ICRA Limited』（2026年10月23日公開、PDF、適時開示）
- ［5］eMudhra Limited『ICRA retains eMudhra ratings after TLS certificate incident, notes exit from global business』（2026年10月23日公開）
関係組織
- ［6］Mozilla『Protecting Firefox users following the compromise of eMudhra intermediate certificates』（2026年10月20日公開、2026年10月21日更新）
- ［7］Mozilla『Mozilla Foundation Security Advisory 2026-111: Security Vulnerabilities fixed in Firefox 158.0.1』（2026年10月20日公開）
- ［8］Mozilla『Bug 2083449 - eMudhra: Private key compromise of Intermediate Certificates』（2026年10月20日公開、2026年10月25日閲覧）
- ［9］Mozilla『Bug 1970728 - eMudhra: Invalid CRL signatures』（2025年6月5日公開）
- ［10］Mozilla『Compromised eMudhra Intermediate Certificates』（2026年10月20日公開、2026年10月25日閲覧）
- ［11］Google LLC『Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates』（2026年10月20日公開）
- ［12］Apple Inc.『About the compromised eMudhra intermediate CAs』（2026年10月23日公開）
- ［13］The Go team『[security] Go 1.27.3 and Go 1.26.10 are released』（2026年10月20日公開）
- ［14］Python Software Foundation『Python 3.15.1, 3.14.9 and 3.13.17 are out』（2026年10月21日公開）
- ［15］Red Hat, Inc.『RHSB-2026-012 Certificate compromise - eMudhra (CVE-2026-114406, CVE-2026-111943, CVE-2026-91403, CVE-2026-113812)』（2026年10月21日公開、2026年10月24日更新）
- ［16］Canonical Ltd.『USN-8944-1: ca-certificates update』（2026年10月20日公開）
- ［17］Cloudflare, Inc.『8 eMudhra certificates are compromised. Here's what you need to know』（2026年10月20日公開）
- ［18］Cornell University『Performance Issue: Some websites may need SSL certificates replaced』（2026年10月21日公開、2026年10月22日更新）
- ［19］University of Michigan『Root Certificate Authorities Distrusted』（公開日不明、保存記録のみ） 保存記録
公的機関
- ［20］Indian Computer Emergency Response Team『CERT-In Advisory CIAD-2026-0050 Compromise of eMudhra Intermediate CA Certificates』（2026年10月21日公開）
調査・観測
- ［21］emudhra.we-have-a-problem.com『eMudhra Intermediate CA Compromise』（2026年10月20日公開、2026年10月25日閲覧）
- ［22］emudhra.we-have-a-problem.com『impacted-intermediates.json』（2026年10月20日公開）
- ［23］Scott Helme『Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds』（2026年10月20日公開）
報道機関
- ［24］The Hacker News『Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software』（2026年10月20日公開、2026年10月21日更新）
- ［25］The Hacker News『eMudhra to Exit Global SSL/TLS Business After 8 Intermediate CA Keys Found Easily Guessable』（2026年10月22日公開）
- ［26］ThePrint『MeitY sets up team to probe eMudhra certificate breach, says digital signature services unaffected』（2026年10月21日公開）
更新記録
- 2026年10月25日16時32分：公開した。
- 2026年10月25日18時2分：「ルートプログラムの遮断」のemSign Root CA - G1の扱いに出典［8］の原文にある時点の限定を戻し、表3のPythonの行を3.15.1・3.14.9の前倒しと3.13.17の特別のセキュリティリリースに分け、出典［8］の公開日を起票の2026年10月18日から閲覧制限が解かれた2026年10月20日に改めた。
- 2026年10月25日20時50分：日付の表記を月日の形に改めた。
- 2026年10月26日2時13分：「経緯」のMozillaの予備的な調査の文から中間CAの一群が作られた日を次の文に移し、「影響範囲」のミシガン大学の告知の題を『』で示した。
- 2026年11月2日：〔注1〕の変更の注記が無いという文に、dev-security-policyの参加者の帰属を付けた。