https://wiki.mozilla.org/api.php?action=feedcontributions&user=Bwilson&feedformat=atomMozillaWiki - User contributions [en]2024-03-28T21:24:49ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1249985NSS:Release Versions2024-02-15T14:15:38Z<p>Bwilson: /* Root Cert Inclusions into Mozilla Product Releases */ Add Bug 1879945</p>
<hr />
<div>* '''NSS Release Bug (meta)''' https://bugzilla.mozilla.org/show_bug.cgi?id=1816499<br />
* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
! Release Manager<br />
|-<br />
| 3.97<br />
|<br />
|<br />
| 2024-01-04<br />
| '''2024-01-11'''<br />
| 2024-01-22<br />
| 123<br />
| 2024-02-20<br />
| B. Beurdouche<br />
|-<br />
| 3.98<br />
|<br />
|<br />
| 2024-03-XX<br />
| '''2024-02-15'''<br />
| 2024-02-19<br />
| 124<br />
| 2024-03-19<br />
| Anna<br />
|-<br />
| 3.99<br />
|<br />
|<br />
| 2024-XX<br />
| '''2024-03-14'''<br />
| 2024-03-18<br />
| 125<br />
| 2024-04-16<br />
| John<br />
|-<br />
| 3.100<br />
|<br />
|<br />
| 2024-XX<br />
| '''2024-04-11'''<br />
| 2024-04-15<br />
| 126<br />
| 2024-05-14<br />
| B. Beurdouche<br />
|-<br />
}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| New NSPR version<br />
| New CA list version<br />
| NSS Beta<br />
| NSS Release<br />
| Firefox merge date<br />
| Firefox version<br />
| Firefox release date<br />
| Release Manager<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.96<br />
|<br />
|<br />
| 2023-12-07<br />
| '''2023-12-14'''<br />
| 2023-12-18<br />
| 122<br />
| 2024-01-23<br />
|-<br />
| 3.95<br />
|<br />
|2.64<br />
| 2023-11-09<br />
| '''2023-11-16'''<br />
| 2023-11-20<br />
| 121<br />
| 2023-12-19<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-09-14<br />
| '''2023-09-21'''<br />
| 2023-09-25<br />
| 119<br />
| 2023-10-24<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-08-18<br />
| '''2023-08-23'''<br />
| 2023-08-25<br />
| 118<br />
| 2023-09-26<br />
|-<br />
| 3.92<br />
|<br />
| 2.62<br />
| 2023-07-12<br />
| '''2023-07-19'''<br />
| 2023-07-27<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.91 <br />(ESR)<br />
|<br />
|<br />
| 2023-06-19<br />
| '''2023-06-26'''<br />
| 2023-06-29<br />
| 116<br />
| 2023-07-04<br />
|-<br />
| Skipped<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<tr><br />
<td>3.98</td> <td><b>{{bug|1870673}}</b>: {{bug|1865450}}, {{bug|1873095}}, {{bug|1874017}}, {{bug|1879945}}</td> <td>124</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<tr><br />
<td>3.94</td> <td><b>{{bug|1842932}}</b>: {{bug|1842935}}, {{bug|1850598}}, {{bug|1850982}}, {{bug|1851044}}, {{bug|1851049}}, {{bug|1855318}}, {{bug|1860670}} </td> <td>121</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
, , , , , , <br />
<tr><br />
<td>3.92</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Incident_Dashboard&diff=1249904CA/Incident Dashboard2024-02-02T22:48:33Z<p>Bwilson: /* Open CA Compliance Bugs */ Minor edit</p>
<hr />
<div>= Open CA Bugs in Bugzilla =<br />
<br />
== Open CA Compliance Bugs ==<br />
A CA compliance bug relates to a concern about a CA's certificates failing to comply with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] and/or a [https://cabforum.org/ CA/Browser Forum] requirement, and is determined to not be an [https://www.mozilla.org/en-US/security/#For_Developers imminent security concern]. A CA's response to a CA compliance bug includes providing an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]] in the bug.<br />
<br />
Anyone may create a CA Compliance bug as follows:<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other<br />
* Whiteboard = [ca-compliance] <br />
** If the issue is due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][covid-19] <br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "nowordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"f4": "status_whiteboard",<br />
"o4": "nowordssubstr",<br />
"v4": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
== Audit Delays ==<br />
The compliance bug's whiteboard field is tagged with [audit-delay] whenever a CA is unable to deliver audit statements to Mozilla [[CA/Audit_Statements|when they are due]]. Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], with the following whiteboard tags as described [https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay here].<br />
*Whiteboard = [ca-compliance][audit-delay]<br />
*For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
== Revocation Delays ==<br />
The compliance bug's whiteboard field is tagged with [ca-revocation-delay] or [leaf-revocation-delay] whenever a CA fails to abide by Mozilla's requirement to revoke certificates in a timely fashion. As discussed in [[CA/Responding_To_An_Incident#Revocation]], Mozilla recognizes that there may be *exceptional* situations that cause a CA to not abide by the Baseline Requirements, which should be accompanied by an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]].<br />
<br />
Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], and will be categorized appropriately during triage.<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
= Closed CA Bugs =<br />
== Closed CA Compliance Bugs ==<br />
A historical view of past CA compliance bugs may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_Incidents</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Incident_Dashboard&diff=1249903CA/Incident Dashboard2024-02-02T22:44:51Z<p>Bwilson: /* Revocation Delays */ Edited query</p>
<hr />
<div>= Open CA Bugs in Bugzilla =<br />
<br />
== Open CA Compliance Bugs ==<br />
A CA compliance bug relates to a concern about a CA's certificates failing to comply with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] and/or the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements], and is determined to not be an [https://www.mozilla.org/en-US/security/#For_Developers imminent security concern]. A CA's response to CA compliance bug includes providing an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]] in the bug.<br />
<br />
Anyone may create a CA Compliance bug as follows:<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other<br />
* Whiteboard = [ca-compliance] <br />
** If the issue is due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][covid-19] <br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "nowordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"f4": "status_whiteboard",<br />
"o4": "nowordssubstr",<br />
"v4": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
== Audit Delays ==<br />
The compliance bug's whiteboard field is tagged with [audit-delay] whenever a CA is unable to deliver audit statements to Mozilla [[CA/Audit_Statements|when they are due]]. Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], with the following whiteboard tags as described [https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay here].<br />
*Whiteboard = [ca-compliance][audit-delay]<br />
*For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
== Revocation Delays ==<br />
The compliance bug's whiteboard field is tagged with [ca-revocation-delay] or [leaf-revocation-delay] whenever a CA fails to abide by Mozilla's requirement to revoke certificates in a timely fashion. As discussed in [[CA/Responding_To_An_Incident#Revocation]], Mozilla recognizes that there may be *exceptional* situations that cause a CA to not abide by the Baseline Requirements, which should be accompanied by an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]].<br />
<br />
Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], and will be categorized appropriately during triage.<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
= Closed CA Bugs =<br />
== Closed CA Compliance Bugs ==<br />
A historical view of past CA compliance bugs may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_Incidents</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Incident_Dashboard&diff=1249902CA/Incident Dashboard2024-02-02T22:43:40Z<p>Bwilson: /* Revocation Delays */ Edited query</p>
<hr />
<div>= Open CA Bugs in Bugzilla =<br />
<br />
== Open CA Compliance Bugs ==<br />
A CA compliance bug relates to a concern about a CA's certificates failing to comply with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] and/or the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements], and is determined to not be an [https://www.mozilla.org/en-US/security/#For_Developers imminent security concern]. A CA's response to CA compliance bug includes providing an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]] in the bug.<br />
<br />
Anyone may create a CA Compliance bug as follows:<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other<br />
* Whiteboard = [ca-compliance] <br />
** If the issue is due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][covid-19] <br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "nowordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"f4": "status_whiteboard",<br />
"o4": "nowordssubstr",<br />
"v4": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
== Audit Delays ==<br />
The compliance bug's whiteboard field is tagged with [audit-delay] whenever a CA is unable to deliver audit statements to Mozilla [[CA/Audit_Statements|when they are due]]. Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], with the following whiteboard tags as described [https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay here].<br />
*Whiteboard = [ca-compliance][audit-delay]<br />
*For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
== Revocation Delays ==<br />
The compliance bug's whiteboard field is tagged with [ca-revocation-delay] or [leaf-revocation-delay] whenever a CA fails to abide by Mozilla's requirement to revoke certificates in a timely fashion. As discussed in [[CA/Responding_To_An_Incident#Revocation]], Mozilla recognizes that there may be *exceptional* situations that cause a CA to not abide by the Baseline Requirements, which should be accompanied by an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]].<br />
<br />
Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], and will be categorized appropriately during triage.<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "leaf-revocation-delay" OR "ca-revocation-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
= Closed CA Bugs =<br />
== Closed CA Compliance Bugs ==<br />
A historical view of past CA compliance bugs may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_Incidents</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Incident_Dashboard&diff=1249901CA/Incident Dashboard2024-02-02T22:41:54Z<p>Bwilson: /* Audit Delays */ Edited query</p>
<hr />
<div>= Open CA Bugs in Bugzilla =<br />
<br />
== Open CA Compliance Bugs ==<br />
A CA compliance bug relates to a concern about a CA's certificates failing to comply with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] and/or the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements], and is determined to not be an [https://www.mozilla.org/en-US/security/#For_Developers imminent security concern]. A CA's response to CA compliance bug includes providing an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]] in the bug.<br />
<br />
Anyone may create a CA Compliance bug as follows:<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other<br />
* Whiteboard = [ca-compliance] <br />
** If the issue is due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][covid-19] <br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "nowordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"f4": "status_whiteboard",<br />
"o4": "nowordssubstr",<br />
"v4": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
== Audit Delays ==<br />
The compliance bug's whiteboard field is tagged with [audit-delay] whenever a CA is unable to deliver audit statements to Mozilla [[CA/Audit_Statements|when they are due]]. Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], with the following whiteboard tags as described [https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay here].<br />
*Whiteboard = [ca-compliance][audit-delay]<br />
*For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
== Revocation Delays ==<br />
The compliance bug's whiteboard field is tagged with [ca-revocation-delay] or [leaf-revocation-delay] whenever a CA fails to abide by Mozilla's requirement to revoke certificates in a timely fashion. As discussed in [[CA/Responding_To_An_Incident#Revocation]], Mozilla recognizes that there may be *exceptional* situations that cause a CA to not abide by the Baseline Requirements, which should be accompanied by an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]].<br />
<br />
Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], and will be categorized appropriately during triage.<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"f4": "status_whiteboard",<br />
"o4": "allwordssubstr",<br />
"v4": "ca-revocation-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC, delta_ts ASC"<br />
}<br />
</bugzilla><br />
<br />
= Closed CA Bugs =<br />
== Closed CA Compliance Bugs ==<br />
A historical view of past CA compliance bugs may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_Incidents</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Incident_Dashboard&diff=1249900CA/Incident Dashboard2024-02-02T22:40:51Z<p>Bwilson: /* Revocation Delays */ Edited query</p>
<hr />
<div>= Open CA Bugs in Bugzilla =<br />
<br />
== Open CA Compliance Bugs ==<br />
A CA compliance bug relates to a concern about a CA's certificates failing to comply with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] and/or the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements], and is determined to not be an [https://www.mozilla.org/en-US/security/#For_Developers imminent security concern]. A CA's response to CA compliance bug includes providing an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]] in the bug.<br />
<br />
Anyone may create a CA Compliance bug as follows:<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other<br />
* Whiteboard = [ca-compliance] <br />
** If the issue is due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][covid-19] <br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "nowordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"f4": "status_whiteboard",<br />
"o4": "nowordssubstr",<br />
"v4": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
== Audit Delays ==<br />
The compliance bug's whiteboard field is tagged with [audit-delay] whenever a CA is unable to deliver audit statements to Mozilla [[CA/Audit_Statements|when they are due]]. Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], with the following whiteboard tags as described [https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay here].<br />
*Whiteboard = [ca-compliance][audit-delay]<br />
*For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC, delta_ts DESC"<br />
}<br />
</bugzilla><br />
<br />
== Revocation Delays ==<br />
The compliance bug's whiteboard field is tagged with [ca-revocation-delay] or [leaf-revocation-delay] whenever a CA fails to abide by Mozilla's requirement to revoke certificates in a timely fashion. As discussed in [[CA/Responding_To_An_Incident#Revocation]], Mozilla recognizes that there may be *exceptional* situations that cause a CA to not abide by the Baseline Requirements, which should be accompanied by an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]].<br />
<br />
Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], and will be categorized appropriately during triage.<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"f4": "status_whiteboard",<br />
"o4": "allwordssubstr",<br />
"v4": "ca-revocation-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC, delta_ts ASC"<br />
}<br />
</bugzilla><br />
<br />
= Closed CA Bugs =<br />
== Closed CA Compliance Bugs ==<br />
A historical view of past CA compliance bugs may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_Incidents</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Incident_Dashboard&diff=1249899CA/Incident Dashboard2024-02-02T22:38:21Z<p>Bwilson: /* Open CA Compliance Bugs */ Edited query</p>
<hr />
<div>= Open CA Bugs in Bugzilla =<br />
<br />
== Open CA Compliance Bugs ==<br />
A CA compliance bug relates to a concern about a CA's certificates failing to comply with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] and/or the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements], and is determined to not be an [https://www.mozilla.org/en-US/security/#For_Developers imminent security concern]. A CA's response to CA compliance bug includes providing an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]] in the bug.<br />
<br />
Anyone may create a CA Compliance bug as follows:<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other<br />
* Whiteboard = [ca-compliance] <br />
** If the issue is due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][covid-19] <br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "nowordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"f4": "status_whiteboard",<br />
"o4": "nowordssubstr",<br />
"v4": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
== Audit Delays ==<br />
The compliance bug's whiteboard field is tagged with [audit-delay] whenever a CA is unable to deliver audit statements to Mozilla [[CA/Audit_Statements|when they are due]]. Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], with the following whiteboard tags as described [https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay here].<br />
*Whiteboard = [ca-compliance][audit-delay]<br />
*For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC, delta_ts DESC"<br />
}<br />
</bugzilla><br />
<br />
== Revocation Delays ==<br />
The compliance bug's whiteboard field is tagged with [delayed-revocation-ca] or [delayed-revocation-leaf] whenever a CA fails to abide by Mozilla's requirement to revoke certificates in a timely fashion. As discussed in [[CA/Responding_To_An_Incident#Revocation]], Mozilla recognizes that there may be *exceptional* situations that cause a CA to not abide by the Baseline Requirements, which should be accompanied by an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]].<br />
<br />
Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], and will be categorized appropriately during triage.<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC, delta_ts ASC"<br />
}<br />
</bugzilla><br />
<br />
= Closed CA Bugs =<br />
== Closed CA Compliance Bugs ==<br />
A historical view of past CA compliance bugs may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_Incidents</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Incident_Dashboard&diff=1249898CA/Incident Dashboard2024-02-02T22:34:37Z<p>Bwilson: /* Revocation Delays */ Changed query</p>
<hr />
<div>= Open CA Bugs in Bugzilla =<br />
<br />
== Open CA Compliance Bugs ==<br />
A CA compliance bug relates to a concern about a CA's certificates failing to comply with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] and/or the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements], and is determined to not be an [https://www.mozilla.org/en-US/security/#For_Developers imminent security concern]. A CA's response to CA compliance bug includes providing an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]] in the bug.<br />
<br />
Anyone may create a CA Compliance bug as follows:<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other<br />
* Whiteboard = [ca-compliance] <br />
** If the issue is due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][covid-19] <br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "nowordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"o4": "nowordssubstr",<br />
"v4": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
== Audit Delays ==<br />
The compliance bug's whiteboard field is tagged with [audit-delay] whenever a CA is unable to deliver audit statements to Mozilla [[CA/Audit_Statements|when they are due]]. Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], with the following whiteboard tags as described [https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay here].<br />
*Whiteboard = [ca-compliance][audit-delay]<br />
*For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC, delta_ts DESC"<br />
}<br />
</bugzilla><br />
<br />
== Revocation Delays ==<br />
The compliance bug's whiteboard field is tagged with [delayed-revocation-ca] or [delayed-revocation-leaf] whenever a CA fails to abide by Mozilla's requirement to revoke certificates in a timely fashion. As discussed in [[CA/Responding_To_An_Incident#Revocation]], Mozilla recognizes that there may be *exceptional* situations that cause a CA to not abide by the Baseline Requirements, which should be accompanied by an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]].<br />
<br />
Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], and will be categorized appropriately during triage.<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC, delta_ts ASC"<br />
}<br />
</bugzilla><br />
<br />
= Closed CA Bugs =<br />
== Closed CA Compliance Bugs ==<br />
A historical view of past CA compliance bugs may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_Incidents</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Incident_Dashboard&diff=1249897CA/Incident Dashboard2024-02-02T22:33:13Z<p>Bwilson: /* Open CA Compliance Bugs */ Changed query</p>
<hr />
<div>= Open CA Bugs in Bugzilla =<br />
<br />
== Open CA Compliance Bugs ==<br />
A CA compliance bug relates to a concern about a CA's certificates failing to comply with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] and/or the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements], and is determined to not be an [https://www.mozilla.org/en-US/security/#For_Developers imminent security concern]. A CA's response to CA compliance bug includes providing an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]] in the bug.<br />
<br />
Anyone may create a CA Compliance bug as follows:<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other<br />
* Whiteboard = [ca-compliance] <br />
** If the issue is due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][covid-19] <br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "nowordssubstr",<br />
"v3": "leaf-revocation-delay",<br />
"o4": "nowordssubstr",<br />
"v4": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC"<br />
}<br />
</bugzilla><br />
<br />
== Audit Delays ==<br />
The compliance bug's whiteboard field is tagged with [audit-delay] whenever a CA is unable to deliver audit statements to Mozilla [[CA/Audit_Statements|when they are due]]. Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], with the following whiteboard tags as described [https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay here].<br />
*Whiteboard = [ca-compliance][audit-delay]<br />
*For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "audit-delay",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC, delta_ts DESC"<br />
}<br />
</bugzilla><br />
<br />
== Revocation Delays ==<br />
The compliance bug's whiteboard field is tagged with [delayed-revocation-ca] or [delayed-revocation-leaf] whenever a CA fails to abide by Mozilla's requirement to revoke certificates in a timely fashion. As discussed in [[CA/Responding_To_An_Incident#Revocation]], Mozilla recognizes that there may be *exceptional* situations that cause a CA to not abide by the Baseline Requirements, which should be accompanied by an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]].<br />
<br />
Such bugs should be reported as [[CA/Bug_Triage#Compliance_Problems_and_Incidents|CA compliance issues]], and will be categorized appropriately during triage.<br />
<br />
<bugzilla><br />
{<br />
"component":"CA Certificate Compliance",<br />
"status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], <br />
"f1": "OP",<br />
"j1": "AND",<br />
"f2": "status_whiteboard",<br />
"o2": "allwordssubstr",<br />
"v2": "ca-compliance",<br />
"f3": "status_whiteboard",<br />
"o3": "allwordssubstr",<br />
"v3": "delayed-revocation",<br />
"include_fields": "summary, id, status, assigned_to, whiteboard, last_change_time, creation_time",<br />
"order": "short_desc ASC, delta_ts ASC"<br />
}<br />
</bugzilla><br />
<br />
<br />
= Closed CA Bugs =<br />
== Closed CA Compliance Bugs ==<br />
A historical view of past CA compliance bugs may be found here:<br />
* https://wiki.mozilla.org/CA/Closed_Incidents</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1249864NSS:Release Versions2024-01-31T21:51:19Z<p>Bwilson: /* Root Cert Inclusions into Mozilla Product Releases */ Added NSS 3.98 / FF121</p>
<hr />
<div>* '''NSS Release Bug (meta)''' https://bugzilla.mozilla.org/show_bug.cgi?id=1816499<br />
* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
! Release Manager<br />
|-<br />
| 3.97<br />
|<br />
|<br />
| 2024-01-04<br />
| '''2024-01-11'''<br />
| 2024-01-22<br />
| 123<br />
| 2024-02-20<br />
| B. Beurdouche<br />
|-<br />
| 3.98<br />
|<br />
|<br />
| 2024-03-XX<br />
| '''2024-02-15'''<br />
| 2024-02-19<br />
| 124<br />
| 2024-03-19<br />
| Anna<br />
|-<br />
| 3.99<br />
|<br />
|<br />
| 2024-XX<br />
| '''2024-03-14'''<br />
| 2024-03-18<br />
| 125<br />
| 2024-04-16<br />
| John<br />
|-<br />
| 3.100<br />
|<br />
|<br />
| 2024-XX<br />
| '''2024-04-11'''<br />
| 2024-04-15<br />
| 126<br />
| 2024-05-14<br />
| B. Beurdouche<br />
|-<br />
}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| New NSPR version<br />
| New CA list version<br />
| NSS Beta<br />
| NSS Release<br />
| Firefox merge date<br />
| Firefox version<br />
| Firefox release date<br />
| Release Manager<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.96<br />
|<br />
|<br />
| 2023-12-07<br />
| '''2023-12-14'''<br />
| 2023-12-18<br />
| 122<br />
| 2024-01-23<br />
|-<br />
| 3.95<br />
|<br />
|2.64<br />
| 2023-11-09<br />
| '''2023-11-16'''<br />
| 2023-11-20<br />
| 121<br />
| 2023-12-19<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-09-14<br />
| '''2023-09-21'''<br />
| 2023-09-25<br />
| 119<br />
| 2023-10-24<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-08-18<br />
| '''2023-08-23'''<br />
| 2023-08-25<br />
| 118<br />
| 2023-09-26<br />
|-<br />
| 3.92<br />
|<br />
| 2.62<br />
| 2023-07-12<br />
| '''2023-07-19'''<br />
| 2023-07-27<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.91 <br />(ESR)<br />
|<br />
|<br />
| 2023-06-19<br />
| '''2023-06-26'''<br />
| 2023-06-29<br />
| 116<br />
| 2023-07-04<br />
|-<br />
| Skipped<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<tr><br />
<td>3.98</td> <td><b>{{bug|1870673}}</b>: {{bug|1865450}}, {{bug|1873095}}, {{bug|1874017}}</td> <td>124</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<tr><br />
<td>3.94</td> <td><b>{{bug|1842932}}</b>: {{bug|1842935}}, {{bug|1850598}}, {{bug|1850982}}, {{bug|1851044}}, {{bug|1851049}}, {{bug|1855318}}, {{bug|1860670}} </td> <td>121</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
, , , , , , <br />
<tr><br />
<td>3.92</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Forbidden_or_Problematic_Practices&diff=1249756CA/Forbidden or Problematic Practices2024-01-23T16:16:31Z<p>Bwilson: /* Non-Standard Email Address Prefixes for Domain Ownership Validation */ Updated allowed email contacts</p>
<hr />
<div>This page contains comments about various CA practices that have been the subject of discussion in past CA evaluations. Some of these practices are addressed by the [http://www.mozilla.org/projects/security/certs/policy Mozilla Root Store Policy] and are forbidden. They are listed here because they are things CAs often get wrong. Others, we do not necessarily consider security risks, but we want to highlight them because they've occasioned controversy in the past and have in some cases caused approval of applications to be delayed. Additional practices may be addressed in future versions of the policy.<br />
<br />
== Forbidden Practices ==<br />
<br />
=== Long-lived Certificates ===<br />
<br />
Section 6.3.2 of the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] states: "Subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and '''MUST NOT have a Validity Period greater than 398 days'''."<br />
<br />
=== Non-Standard Email Address Prefixes for Domain Ownership Validation ===<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] requires CAs to conform to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements (BRs)] in the issuance and management of publicly trusted TLS server certificates. This includes the BR restrictions on the use of email as a way of validating that the certificate subscriber owns or controls the domain name to be included in the certificate. CAs are expected to conform to BR section 3.2.2.4, which allows email to the "Domain Contact", defined as the "Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS<br />
SOA record, or as obtained through direct contact with the Domain Name Registrar." (BR § 3.2.2.4.2); a selected whitelist of constructed addresses, which are limited to local-parts of "admin", "administrator", "webmaster", "hostmaster", and "postmaster" followed by the "at" sign ("@") and the domain name in question (read BR § 3.2.2.4.4 for specifics); or using email addresses found in DNS (BR § 3.2.2.4.13 and BR § 3.2.2.4.14).<br />
<br />
A CA that authorizes certificate subscribers by contacting any other email addresses may be found non-compliant with Mozilla's Root Store Policy and in violation of the Baseline Requirements, and may have action taken against it. CAs are also reminded that Mozilla's Root Store Policy and the Baseline Requirements extend to any CA certificates that are technically capable of issuing TLS server certificates, and subordinate CAs that fail to follow these requirements put the root CA in jeopardy of removal from Mozilla's root store.<br />
<br />
=== Issuing End Entity Certificates Directly From Roots ===<br />
<br />
This is forbidden by section 6.1.7 of the Baseline Requirements.<br />
<br />
=== Distributing Generated Private Keys in PKCS#12 Files ===<br />
<br />
Section 5.2 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#52-forbidden-and-required-practices Mozilla's Root Store Policy] states: "CA operators MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage, unless the certificate is being issued to the CA itself."<br />
<br />
In other words, CAs must note generate key pairs for TLS server certificates, except for their own use (e.g. certificates for the test websites required by BR section 2.2). CAs may only generate the key pairs for S/MIME certificates. Distribution or transfer of S/MIME certificates in unprotected PKCS#12 form through unsecure electronic channels is not allowed. If a PKCS#12 file is distributed via a physical data storage device, then:<br />
* The storage must be packaged in a way that the opening of the package causes irrecoverable physical damage. (e.g. a security seal)<br />
* The PKCS#12 file must have a sufficiently secure password, and the password must not be transferred together with the storage.<br />
<br />
=== Certificates Referencing Local Names or Private IP Addresses ===<br />
<br />
A Subject Alternative Name (SAN) with an internal or local name or with a reserved or private IP address is forbidden by section 7.1.4.2.1 of the [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements]. <br />
<br />
=== OCSP Responses Signed by a Certificate Under a Different Root ===<br />
<br />
CAs who issue certificates with OCSP URLs in AIA extensions should make sure that the OCSP responses conform to RFC 6960, and work correctly for Mozilla users without requiring the user to find and install the OCSP responder's certificate, that is, the certificate with which the OCSP response signatures are verified.<br />
<br />
RFC 6960, sections 2.2, 2.6, 3.2 and 4.2.2.2 define the requirements for the OCSP response signer's certificate and certificate chain. NSS enforces these requirements exactly.<br />
<br />
For a detailed explanation about why an OCSP responder should not use a self-signed OCSP responder certificate and depend on Trusted Responder Mode within the Firefox browser, see: [[CA:OCSP-TrustedResponder|Details about OCSP Trusted Responder Mode.]]<br />
<br />
Please test your OCSP responder within the Firefox browser by enforcing OCSP as per our [[CA:Recommended_Practices#OCSP|CA Recommended Practices for OCSP.]]<br />
<br />
=== Issuance of SHA-1 Certificates ===<br />
<br />
Issuance of SHA-1 subordinate CA certificates, end entity certificates, or OCSP responder certificates is forbidden by [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#51-algorithms section 5.1 of Mozilla's Root Store Policy] and section 7.1.3.2.1 of the [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements]. Other uses of SHA-1 are also being phased out. See [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#513-sha-1 MRSP § 5.1.3].<br />
<br />
=== Delegation of Domain / Email Validation to Third Parties ===<br />
<br />
Section 1.3.2 of the [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements] forbids delegating domain validation to third parties.<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Section 2.2 of Mozilla's Root Store Policy] says: "The CA operator SHALL NOT delegate validation of the domain portion of an email address."<br />
<br />
Domain and Email validation are core requirements of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] and should always be incorporated into the issuing CA's procedures. Delegating this function to third parties is not permitted.<br />
<br />
== Potentially Problematic Practices ==<br />
<br />
=== Allowing External Entities to Operate Subordinate CAs ===<br />
<br />
Some root CA operators authorize external entities to operate their own CAs as subordinate CAs under the root. In considering a root certificate for inclusion in NSS, Mozilla will evaluate the current subordinate CAs and the selection/approval criteria for future subordinate CAs. This evaluation includes a review of the CA's approval criteria, as well as the documentation and auditing-of-operations requirements that the operator of the root CA places on such relationships.<br />
<br />
In order to best ensure the safety and security of Mozilla users, Mozilla has a [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ single consistent policy] that describes the expectations for all CAs that will be trusted within its program. Mozilla requires that all participating root CAs fully disclose their hierarchy, including CP, CPS, and audits, when said hierarchy is capable of TLS server certificate or email certificate issuance.<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#84-externally-operated-subordinate-cas Section 8.4 of the Mozilla Root Store Policy] requires that externally operated CAs undergo public discussion unless they meet one of the enumerated exceptions (e.g. they are already in the root store with the ability to issue the same type of certificate that they were already approved for). See [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#84-externally-operated-subordinate-cas MRSP § 8.4] and [https://wiki.mozilla.org/CA/External_Sub_CAs#Process_for_non-Technically-Constrained_Subordinate_CAs Process for non-Technically-Constrained Subordinate CAs] for details. <br />
<br />
During the root inclusion/change process, CAs must provide a clear description of any subordinate CAs that are operated by external third parties, and an explanation as to how the CP/CPS and audits ensure the third parties are in compliance with CA/Browser Forum and Mozilla's CA Certificate Policy requirements as per the [https://wiki.mozilla.org/CA:SubordinateCA_checklist Subordinate CA Checklist]. <br />
<br />
CAs must disclose their internally and externally operated subordinate CAs in the [https://www.ccadb.org/policy CCADB], and maintain annual updates to the corresponding CP/CPS documents and audit statements. If CP/CPS or audit documents for a particular subordinate CA are different than that of the root CA, then such different documents also need to be reflected in the [https://www.ccadb.org/cas/intermediates CCADB].<br />
<br />
=== Generic Names for CAs ===<br />
<br />
In various contexts Firefox and other Mozilla-based products display to users the names of root CAs, issuing CAs, and intermediate CAs in general. In some cases, CA names are too generic, e.g. "Secure Server CA", which makes it difficult for users to ascertain who operates the CA without undertaking a detailed investigation.<br />
<br />
Our recommendation is that all CA names incorporate an organizational name or product brand name sufficiently unique to allow relatively straightforward identification of the CA.<br />
<br />
Additionally, the issuer and subject information in the root certificate should provide clear indication about who owns or operates the CA. Generic issuer and subject information inhibits the users' ability to establish a chain of trust, and to pursue complaints when appropriate. For instance, the following issuer information would be totally unacceptable in a root certificate to be included in NSS.<br />
* CN = Root CA<br />
* O = admin<br />
There is no information in this issuer that can be linked back to any particular CA operator. There is no distinguishable company name or brand name. All information in this issuer is too generic to do a search on and hope to find the responsible CA operator. (Moreover, it lacks the two‐letter ISO 3166‐1 country code, which is required by section 7.1.4.3 of the Baseline Requirements.) <br />
<br />
'''Important:''' Both the O and the CN must be meaningful, and not generic terms such as "admin" or "root". It is not acceptable for the O not to identify the CA operator and a generic term such as "Admin" will mislead users, who rely on the issuer details, when they hover their mouse over the lock icon in the address bar.<br />
<br />
Also, please refer to sections 7.1.4.1 Name Encoding and 7.1.4.3 Subject Information - Root Certificates and Subordinate CA Certificates in the Baseline Requirements.<br />
<br />
=== Lack of Communication With End Users ===<br />
<br />
CAs should be contactable by, and accept and act upon complaints made by, those relying on their assertions of identity. For CAs included in Mozilla, this will include being responsive to members of the general public, including people who have not purchased products from that CA. See [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements], section 4.9.3, "The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports. The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS."<br />
<br />
=== Backdating the notBefore Date ===<br />
<br />
Certificates do not contain an issue timestamp, so it is not possible to be certain when they were issued. The notBefore date is the start of the certificate's validity range, and is set by the CA. It should be a reasonable reflection of the date on which the certificate was issued. Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline, prohibition, or code-enforced restriction is not.<br />
<br />
=== Issuer Encoding in CRL ===<br />
<br />
The encoding of the Issuer field in the CRL should be byte-for-byte equivalent with the encoding of the Issuer in the certificate; that is, using the exact same string types and field contents. The specs ([https://www.ietf.org/rfc/rfc2459.txt RFC 2459], [https://www.ietf.org/rfc/rfc3280.txt RFC 3280], [https://tools.ietf.org/html/rfc5280#section-7 RFC 5280]) permit them to mismatch, but that causes compatibility issues with various clients -- in such cases client software might not find the entry for the revoked certificate in the CRL.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Required_or_Recommended_Practices&diff=1249333CA/Required or Recommended Practices2024-01-05T18:24:08Z<p>Bwilson: /* Complete Audit History */ Replaced point-in-time audits with concept of period-of-time key lifecycle management reports</p>
<hr />
<div>This page contains a set of practices for CAs wishing to have their root CA certificates included in Mozilla products. In some cases these practices are required by the [http://www.mozilla.org/projects/security/certs/policy Mozilla Root Store Policy] and so are mandatory for a CA to have its root certificate(s) included. They are listed here because they are things CAs often get wrong. In other cases the practices are only recommended, but will help speed up a CA's application for inclusion and maximize the chances of its application being approved.<br />
<br />
== Required Practices ==<br />
<br />
=== Publicly Available CP and CPS ===<br />
<br />
A Certificate Policy (CP) is a named set of rules that indicate the applicability of a certificate to a particular community and/or class of applications with common security requirements. A Certification Practices Statement (CPS) is a document that describes the practices that a Certification Authority (CA) employs in issuing, managing, revoking, and renewing or re-keying certificates. CAs must supply a complete CPS, or also a CP, or a combined CP/CPS ("CP/CPS" herein) containing sufficient information to determine whether and how the CA complies with Mozilla policy requirements.<br />
<br />
* The CP/CPS must be publicly available from the CA's official web site.<br />
* The CP/CPS must clearly indicate which root and subordinate certificates the practices and processes described in those documents apply to.<br />
* The format of the CP/CPS must be PDF or another suitable format for reading documents. CAs should ''not'' use Microsoft Word or other formats intended primarily for editable documents.<br />
* The CP/CPS must be available in an English version. The non-English version may be authoritative (as that's the working language of the CA) but the CA is responsible for ensuring that the translation is not materially different from the authoritative version of the document.<br />
* As part of the inclusion process and the [https://wiki.mozilla.org/CA/Compliance_Self-Assessment CA Compliance Self-Assessment], CAs must provide the CP/CPS sections that address the requirements of Mozilla policy and the Baseline Requirements.<br />
<br />
===== CP/CPS Revision Table =====<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses Section 3.3 of Mozilla's Root Store Policy] requires that a CA review and update its CP/CPS at least once every twelve months. CAs must "indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document." This is also required by section 2.3 of the [https://cabforum.org/baseline-requirements-documents Baseline Requirements].<br />
<br />
===== CAA Domains listed in CP/CPS =====<br />
<br />
Section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs] states: "Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully‐Qualified Domain Names; that policy shall be consistent with these Requirements. It shall clearly specify the set of Issuer Domain Names that the CA recognizes in CAA “issue” or “issuewild” records as permitting it to issue."<br />
<br />
===== BR Commitment to Comply statement in CP/CPS =====<br />
<br />
For root certificates with the Websites (TLS/SSL) trust bit enabled, Mozilla requires that the corresponding CP/CPS documents include a statement of commitment to comply with the CA/Browser Forum's Baseline Requirements, as per section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs.]<br />
<br />
===== CP/CPS Structured According to RFC 3647 =====<br />
CP/CPS documents must be structured according to RFC 3647. This requirement is stated in section 2.2 of the CA/Browser Forum Baseline Requirements. Further, CP/CPS documents should include every component and subcomponent, and the placement of information should be aligned with the BRs; e.g. domain validation practices should be documented in section 3.2.2.4 of the CA’s CP/CPS.<br />
* The words "''No Stipulation''" mean that "the particular document imposes no requirements related to that section," [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses MRSP section 3.3]. <br />
* The words "''Not applicable''" are acceptable to indicate that the CA’s policies forbid the practice that is the title of the section. Language similar to “We do not perform <subject of the section>” is preferred. <br />
* Sections must not be left blank. The purpose of "No Stipulation" is to make it clear that the omission of content was intentional. <br />
* If a full description of a section is repeated elsewhere in the document, language similar to “Refer to Section 1.2.3” is preferred. Extensive cross-referencing among multiple CPs and CPSes is discouraged. However, cross-referencing between single CP and CPS documents is acceptable as long as both documents are published on your CA's website, and the CP and CPS documents clearly indicate which root certificates they govern.<br />
* If a section in your CP/CPS only applies to a certain type of certificate, then your CP/CPS needs to state that. [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#52-forbidden-and-required-practices Mozilla's Root Store Policy] says: "CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage, unless the certificate is being issued to the CA itself." So if your CP/CPS allows for generation and escrow of private keys for personal certificates, then your CP/CPS should clearly indicate that those sections do not apply to TLS server certificates.<br />
<br />
Examples:<br />
* If your CA does not allow a particular domain validation method to be used, then the CP or CPS should say that, e.g. "This method of domain validation is not used".<br />
* If a section of your CP delegates the detailing of requirements to the CPS, then the CP should state "Refer to <section> of the CPS".<br />
* The BRs do not allow certificate suspension, so the CA’s CPS should state that certificate suspension is not allowed for TLS certificates, and then the other sections related to suspension should say “Not applicable”.<br />
* If your CA does not issue TLS server certificates containing IP addresses, then section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS should say that such certificate issuance is not allowed, e.g. “No IP address certificates are issued under this CPS.”<br />
* If your CP contains full descriptions of physical security required by section 5.1 of RFC 3647, then the CPS may say "As stipulated in section 5.1 of the CP". (This assumes that the CP is also published on your website, and the CP and CPS documents clearly indicate which root certificates they govern.)<br />
<br />
===== CP/CPS Documents will be Reviewed! =====<br />
<br />
During the [[CA/Application_Verification#Detailed_Review|Detailed Review]] phase, <br />
your CP/CPS documentation will be thoroughly reviewed and commented on. Concerns raised by the reviewer must be sufficiently resolved before the request will be allowed to enter [[CA/Application_Verification#Public_discussion|public discussion]]. <br />
<br />
'''[[CA/CPS_Review | Previous reviews of CP/CPS documents]]'''<br />
<br />
=== Audit Criteria ===<br />
<br />
CAs must supply evidence of their being evaluated according to one or more of the Mozilla policy's [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#311-audit-criteria acceptable audit criteria].<br />
<br />
* The CA must indicate exactly which criteria they are being evaluated against (i.e., which of the criteria listed in the Mozilla policy).<br />
* All documents supplied as evidence must be publicly available.<br />
* Documents purporting to be from the CA's auditor (or other evaluator) should be available directly from the auditor (e.g. as documents downloadable from the auditor's website or from CPA Canada's Webtrust seal repository).<br />
<br />
==== Complete Audit History ====<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#71-inclusions Mozilla's Root Store Policy] states: "Before being included, CAs MUST provide evidence that their CA certificates fully comply with the current Mozilla Root Store Requirements and Baseline Requirements, and have continually, from the time of CA private key creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements." It also states, "Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually from the time of CA key pair generation until the CA public key is no longer trusted by Mozilla's root store." ([https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#313-audit-parameters MRSP § 3.1.3]) To meet these requirements, CAs must provide public-facing audit statements for all audits that have been conducted from the time of CA key creation, for both the root and the non-[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#531-technically-constrained technically-constrained] intermediate certificates in the hierarchy.<br />
<br />
This includes:<br />
* Root key generation report<br />
* Period of time audits covering root private key protection (e.g. a period-of-time key lifecycle management report providing reasonable assurance that the CA operator protected CA private keys following root key generation)<br />
<br />
This requirement may be met via one of the following options:<br />
* Providing the sequence of audit statements on the CA's website.<br />
* Attaching the sequence of audit statements to the root inclusion request (Bugzilla Bug).<br />
<br />
CAs must also provide audit information in compliance with [https://www.ccadb.org/policy#5-policies-practices-and-audit-information section 5 of the CCADB Policy].<br />
<br />
=== Revocation of Compromised Certificates ===<br />
<br />
CAs must revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid. CAs must use CRL revocation reason codes in accordance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#611-end-entity-tls-certificate-crlrevocation-reasons MRSP section 6.1.1]. See also [https://wiki.mozilla.org/CA/Revocation_Reasons Revocation Reasons] for additional guidance.<br />
<br />
=== Verifying Domain Name Ownership ===<br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
In accordance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices section 2.2 of Mozilla's Root Store Policy], all domains in a certificate capable of being used for TLS must be verified using one of the methods documented in section 3.2.2.4 of the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements]. The CA's practices documentation (e.g. its CPS) must clearly specify and detail the procedure(s) that the CA employs, including which subsection of 3.2.2.4 it is complying with.<br />
<br />
It also needs to provide sufficient information describing the steps taken by the CA to confirm that the applicant owns/controls the domain names to be included in the certificate. For instance, if a challenge-response procedure is used, then there must be a description of the process. If public resources are used, then there must be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the applicant owns/controls the domain names.<br />
<br />
===== Baseline Requirements =====<br />
<br />
It is '''not''' sufficient to simply reference section 3.2.2.4 of the [https://cabforum.org/baseline-requirements-documents/ CA/Brower Forum's Baseline Requirements]. The BRs list several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing a subsection within section 3.2.2.4 of the BRs does not specify what the CA does, and is insufficient for describing how the CA conforms to the BRs. Section 2.3 of the BRs says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes '''in detail''' how the CA implements the latest version of these Requirements."<br />
<br />
'''Important:'''<br />
* A CPS must state what the CA actually does, not what it could do, such as which of the allowed domain validation methods the CA uses.<br />
* The following validation methods are prohibited: BR subsections 3.2.2.4.1, BR 3.2.2.4.3, BR 3.2.2.4.5, BR 3.2.2.4.6, BR 3.2.2.4.9, BR 3.2.2.4.10, BR 3.2.2.4.11, and BR 3.2.2.5.4.<br />
<br />
===== WHOIS and DNS =====<br />
<br />
[http://en.wikipedia.org/wiki/WHOIS WHOIS] and DNS are used by CAs as a source of information for checking <br />
ownership/control of the domain name for TLS certificate applications. WHOIS and DNS information may be subject to compromise (e.g. [https://en.wikipedia.org/wiki/BGP_hijacking BGP hijacking]). CAs are responsible for implementing appropriate methods to reduce the risk that a domain validation method has been compromised. For example, a CA could use direct command line, HTTPS to the original registrar, DNSSEC, or correlate multiple sources of WHOIS and DNS information. The CA should disclose the methods that it uses to ensure the integrity of the data.<br />
<br />
It is not sufficient for the CP/CPS to just state that WHOIS is checked. The CP/CPS needs to have a high-level description of how the WHOIS information is used. What information must match with that provided by the certificate subscriber? Is a phone call made or email sent to the technical or administrative contact field of the domain's WHOIS record? If an email is sent, does it include non-predictable information that the technical or administrative contact must use to respond?<br />
<br />
===== Email Challenge-Response =====<br />
<br />
Many CAs use an email challenge-response mechanism to verify that the TLS certificate subscriber owns/controls the domain to be included in the certificate. Some CAs allow applicants to select an address from a predetermined list to be used for this verification. See [[CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs|Mozilla's restrictions on the set of verification addresses that may be used.]]<br />
<br />
CAs using this method of domain validation must ensure that they are using the full email, and that none of their systems misinterpret the localpart of an email. If your system fails to process the exact email, it will misinterpret the '+' sign as a delimiter. Consider, for example, the WHOIS contact information for a domain of "user+word@example.com" or "user=word@example.com". Both of these email addresses conform to the rules set out in RFC 822 with respect to the 'localpart' syntax. If your system emails to "word@example.com", rather than to the full "user+word@example.com" / "user=word@example.com", it will allow an attacker (who obtains "word@example.com") to obtain certificates for example.com. Please work with your engineering department to ensure that your systems properly handle such cases, as well as handling variations, such as quoted-string, as also detailed in RFC 822 and subsequent RFCs. This is especially important as EAI addresses (described in RFC 6530 and related) come into play.<br />
<br />
=== Verifying Email Address Control === <br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices Section 2.2 of Mozilla's Root Store Policy] states: "For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification."<br />
<br />
The CA's public documentation needs to provide sufficient information describing how the email address is verified to be owned/controlled by the certificate subscriber. For instance, if a challenge-response type of procedure is used, then there must be a description of the process. If public resources are used, then there must be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the email address.<br />
<br />
The recommended way to satisfy this requirement is to perform a challenge-response type of procedure in which the CA sends email to the email address to be included in the certificate, and the applicant must respond in a way that demonstrates that they have control over that email address. For instance, the CA may send an email to the address to be included in the certificate, containing secret unpredictable information, giving the applicant a limited time to use the information within.<br />
<br />
It is not sufficient for the CP/CPS to just say that an email is sent to the customer. The CP/CPS needs to be clear that the RA sends email to the email address to be included in the certificate. The CP/CPS needs to be clear that the email shall contain some non-predictable information that the subscriber must then use or respond with to confirm that the owner of the email address actually received the email and responded.<br />
<br />
=== DNS names go in SAN ===<br />
<br />
According to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements:]<br />
* Section 7.1.4.2.1 states:<br />
** Certificate Field: '''extensions:subjectAltName'''<br />
** Required/Optional: '''Required'''<br />
** Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted.<br />
* Section 7.1.4.2.2 states:<br />
** Certificate Field: '''subject:commonName''' (OID 2.5.4.3)<br />
** Required/Optional: Deprecated ('''Discouraged''', but not prohibited)<br />
** Contents: If present, this field '''MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension''' (see Section 7.1.4.2.1).<br />
<br />
=== OCSP ===<br />
<br />
OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443. Firefox and some other clients do not work with HTTPS OCSP responders, and many firewalls block requests that aren't over port 80, so OCSP responders must be accessible over HTTP (not only HTTPS) on port 80. <br />
<br />
As per the [https://www.cabforum.org/documents.html CA/Browser Forum’s Baseline Requirements]:<br />
# The OCSP URI must be provided in end entity certificates. (BR section 7.1.2.3.c.)<br />
# OCSP Responders SHALL NOT respond “Good” for Unissued Certificates. (BR section 4.9.10)<br />
# CAs MUST NOT issue OCSP responder certificates using SHA-1 (BR section 7.1.3.2.1)<br />
# OCSP responses MUST conform to RFC6960 and/or RFC5019. (BR section 4.9.9)<br />
<br />
Please refer to section 4.9.10 of the [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements] for additional OCSP requirements.<br />
<br />
You MUST test your OCSP service in Firefox! We expect OCSP responders to function without error in Mozilla products. To test in Firefox:<br />
* Go to Firefox -> Settings -> Privacy & Security -> Certificates<br />
* Check the box for "Query OCSP responder servers to confirm the current validity of certificates"<br />
* You may need to clear your history cache<br />
* Browse to a website whose TLS certificate chains up to your root and has the corresponding OCSP URI in the AIA extension.<br />
<br />
=== Network Security Controls ===<br />
<br />
CAs must maintain current best practices for network security, and have qualified network security audits performed on a regular basis. The [https://www.cabforum.org/ CA/Browser Forum] has published a document called the [https://cabforum.org/network-security-requirements/ Network and Certificate System Security Requirements] (NetSec Requirements) which should be used as guidance for protecting network and supporting systems. CAs should incorporate the NetSec Requirements by reference in either section 5 or section 6.7 of their CP/CPS. <br />
<br />
It is expected that CAs do the following on a regular basis:<br />
* Maintain network security controls that meet the [https://cabforum.org/network-security-requirements/ Network and Certificate System Security Requirements.]<br />
* Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.<br />
* Ensure Intrusion Detection System and other monitoring software is up-to-date.<br />
* Confirm the ability to shut down certificate issuance quickly if alerted of intrusion.<br />
<br />
== Recommended Practices ==<br />
<br />
=== CA Hierarchy ===<br />
<br />
A hierarchical structure of a single-purpose root with intermediate certificates (subordinate CAs) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; subordinate CA certificates (including other self-signed root CA certificates that chain to the trusted root) must be reported in the CCADB. <br />
<br />
CAs that issue certificates under multiple subordinate CAs (i.e. under a root CA whose CA certificate is being requested for inclusion) or under multiple CA hierarchies (i.e. rooted at multiple root CAs, one or more of whose certificates is being requested for inclusion) should provide additional information as noted:<br />
* The CA should provide a graphical or textual description of the CA hierarchy or hierarchies, including which subordinates are under which root CAs.<br />
* The CA should indicate the general types of certificates (i.e. for SSL/TLS servers, email signing/encryption) issued by each subordinate CA under each root.<br />
* Where a CP/CPS applies to multiple subordinate CAs and/or multiple CA hierarchies, the CA should indicate whether particular sections of the CP/CPS apply to different subordinates and/or hierarchies and, if so, what the differences are.<br />
<br />
We strongly recommend that CA operators use separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates for different purposes so that we or others may selectively enable or disable acceptance of certificates issued according to a particular use or policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces).<br />
<br />
=== Document Handling of IDNs in CP/CPS ===<br />
<br />
If a CA allows the use of internationalized domain names (IDNs) in certificates (e.g., as issued for SSL/TLS-enabled servers), the CA should address the issue of homographic spoofing of IDNs in their CP/CPS, even if primary responsibility for dealing with this issue falls on domain registries. (This doesn't mean that the CAs must prevent such spoofing. It merely means that a CA should describe how it handles the issue of spoofing when authenticating the owner of a domain.)<br />
<br />
=== Usage of Appropriate Constraints ===<br />
<br />
Root certificates in Mozilla's program can have either the Websites trust bit set, or the Email trust bit, or both. If only one of those bits is set, relying software will trust certificates in that hierarchy for only that purpose. Nevertheless, it is a best practice for the immediately-issuing intermediate certificate to also contain EKU constraints of either id-kp-serverAuth or id-kp-emailProtection as appropriate, such that if the trust status of the root ever changes (or is not enforced for some reason), the end-entity certificates are still appropriately constrained.<br />
<br />
=== Pre-Issuance Linting ===<br />
<br />
Several tools exist ([https://github.com/certlint/certlint certlint/cablint], [https://github.com/kroeckx/x509lint x509lint], [https://github.com/zmap/zlint zlint]) which can check a tbsCertificate (To Be Signed Certificate - the certificate complete except for the signature) for a large number of standards violations (BRs, RFCs etc.). It is strongly recommended that CAs integrate such tools into their issuance pipelines such that issuance is, minimally, held up for manual review if an error or warning is found. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences, if earlier parts of their pipeline fail in their job of keeping certificates compliant.<br />
<br />
=== Precertificates ===<br />
<br />
Mozilla recommends that CAs log TLS precertificates using [https://www.certificate-transparency.org/ Certificate Transparency] (CT). CAs should be aware of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#54-precertificates section 5.4 of the Mozilla Root Store Policy], and that Mozilla considers logged precertificates as certificates for purposes of determining CA compliance. CAs must be able to revoke precertificates. Mozilla is also planning on requiring that TLS precertificates be logged in CT.<br />
<br />
[https://datatracker.ietf.org/doc/html/rfc9162#section-3.2.1 Section 3.2.1 of RFC 9162] states “a precertificate's signature indicates the CA's binding intent to issue the corresponding certificate, which means that: Misissuance of a precertificate is considered equivalent to misissuance of the corresponding certificate. The CA should expect to be held accountable, even if the corresponding certificate has not actually been issued."<br />
<br />
While [https://cabforum.org/baseline-requirements-documents/ BR] section 7.1.2.5 states “For purposes of clarification, a Precertificate, as described in RFC 6962 – Certificate Transparency, shall not be considered to be a “certificate” subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements”, Mozilla [https://cabforum.org/pipermail/public/2014-January/002694.html interprets] the BR language as a specific exception allowing CAs to issue a precertificate containing the same serial number as the subsequent certificate. Otherwise, Mozilla infers from the existence of a precertificate that a corresponding certificate has been issued.<br />
<br />
Application of RFC 9162 means that:<br />
* A CA must provide OCSP services and responses in accordance with Mozilla policy for all certificates presumed to exist based on the presence of a precertificate, even if the certificate does not actually exist<br />
* A CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under Mozilla policy, even if the certificate does not actually exist.<br />
* If any corresponding certificate with the same serial number and issuer exists, and can not be verified to match the precertificate using the algorithms in RFC 6962, it will be considered misissued.<br />
* In examining historical issuance, the CA must consider both final certificates and precertificates, even if the precertificate did not ultimately result in the issuance of a certificate.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Audit_Statements&diff=1249332CA/Audit Statements2024-01-05T17:54:45Z<p>Bwilson: /* Audit Lifecycle */ Removed quote from CABF's BR section 8.1</p>
<hr />
<div>= Audit Letter Content =<br />
CA Audits are one of the primary mechanisms relied upon by Mozilla to ensure that a CA is operating securely and in compliance with our policies. CA audits and audit statements must comply with the following requirements.<br />
* Section 3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3-documentation Mozilla's Root Store Policy]<br />
* [https://www.ccadb.org/policy#51-audit-statement-content Section 5.1 of the Common CCADB Policy].<br />
* Section 8 of the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements], if the root certificate has the Websites (TLS/SSL) trust bit enabled.<br />
<br />
Format Requirements:<br />
* SHA-256 Fingerprints<br />
** MUST: No colons, no spaces, and no line feeds<br />
** MUST: Uppercase letters<br />
** MUST: be encoded in the document (PDF) as text searchable, not an image<br />
* Dates<br />
** Month DD, YYYY example: May 7, 2016<br />
** DD Month YYYY example: 7 May 2016<br />
** YYYY-MM-DD example: 2016-05-07<br />
** Month names in English<br />
** No extra text within the date, such as “7th” or “the”<br />
<br />
== Audited Locations ==<br />
Both ETSI and WebTrust Audits should:<br />
* Disclose each location (at the state/province level) that was included in the scope of the audit or should have been included in the scope of the audit, whether the inspection was physically carried out in person at each location, and which audit criteria were checked (or not checked) at each location.<br />
** If the CA has more than one location in the same state/province, then use terminology to clarify the number of facilities in that state/province and whether or not all of them were audited. For example: "Facility 1 in Province", "Facility 2 in Province, Facility 3 in Province" '''or''' "Primary Facility in Province", "Secondary Facility in Province", "Tertiary Facility in Province". <br />
*** The public audit statement does not need to identify the type of Facility.<br />
*** "Facility" includes: data center locations, registration authority locations, where IT and business process controls of CA operations are performed, facility hosting an active HSM with CA private keys, facility or bank deposit box storing a deactivated and encrypted copy of a private key.<br />
<br />
= Audit Lifecycle =<br />
Mozilla's Root Store Policy states the following requirements which apply to root certificates and all intermediate certificates that have at least one valid, unrevoked chain up to an included root certificate and which are technically capable of issuing working server or email certificates as described in section 1.1 of Mozilla's [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy] . <br />
* Before being included and periodically thereafter, CAs MUST obtain certain audits for their root certificates and all of their intermediate certificates that are technically capable of issuing working server or email certificates. <br />
* Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually from the time of CA key pair generation until the CA certificate is no longer trusted by Mozilla's root store. <br />
** A CA certificate is considered to be trusted by Mozilla's root store as long as it is not expired, not in OneCRL, and either is directly included in Mozilla's root store or chains up (via subject/issuer) to another certificate that is included in Mozilla's root store. <br />
*** A CA certificate that has the Websites trust bit enabled is considered to be trusted by Mozilla's root store as long as Firefox continues to treat is as either a trusted root certificate or a trusted intermediate certificate. Reference: [[SecurityEngineering/Certificate_Verification|How Firefox Performs Certificate Verification and path construction]] <br />
** Note: If a CA stops providing audit statements for a root certificate for any reason, then the certificate may be added to OneCRL in addition to being removed from Mozilla's root store.<br />
* Successive audits MUST be contiguous (no gaps).<br />
* Audit reports which are being supplied to maintain a certificate within the Mozilla root program MUST be provided to Mozilla via the CCADB within three months of the end date of the period.<br />
* For Intermediate Certificates only: If the CA has a currently valid audit report at the time of creation of the certificate, then the new certificate MUST appear on the CA's next periodic audit reports.<br />
<br />
Other Audits:<br />
* Point-in-Time Audits: Point-in-time audit statements may be used to confirm that all problems previously identified by an auditor in a qualified audit statement have been corrected. However, a point-in-time audit does not replace the period-of-time audit.<br />
* Readiness Assessment: See section 8.1 of the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements].<br />
<br />
= Audit Letter Validation =<br />
The contents of this section and its sub-sections have been moved to https://www.ccadb.org/cas/alv.<br />
== Root Certificates ==<br />
This section has been moved to https://www.ccadb.org/cas/alv#root-certificates<br />
== Intermediate Certificates ==<br />
This section has been moved to https://www.ccadb.org/cas/alv#intermediate-certificates<br />
== Common ALV Findings ==<br />
This section has been moved to https://www.ccadb.org/cas/alv#common-alv-findings<br />
<br />
= Audit Delay =<br />
An Audit Delay is when one or more of the following requirements in section 3.1.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] cannot be met:<br />
* "Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually."<br />
* "... MUST be provided to Mozilla via the CCADB within three months of the point-in-time date or the end date of the period."<br />
<br />
If a CA fails to deliver audit statements to Mozilla when they are due, Mozilla may take action to reduce the risks this presents to our users. The following guidance is intended for CAs in such a situation.<br />
<br /><br /><br />
When a CA realizes that their audits will be delayed by a [https://en.wikipedia.org/wiki/Force_majeure force majeure], Mozilla expects the CA to promptly disclose the issue, to provide regular updates, and to remain fully compliant with all other aspects of the Mozilla Root Store policy. CAs that are unable to deliver timely and complete audit statements should arrange with their auditors to supply Mozilla with partial information whenever possible, via publicly-available audit statements listing qualifications, agreed-upon procedures (AUP) reports, or similar partial reporting mechanisms (described in more detail below).<br />
<br /><br /><br />
The CA must [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other file an incident bug in Bugzilla] to provide an [[CA/Responding_To_An_Incident#Incident_Report|Incident Report]] explaining the situation with their audits, mitigations that have been or will be implemented, and their plan to move forward in reaching compliance again.<br />
* Whiteboard = [ca-compliance][audit-delay]<br />
* For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]<br />
<br />
== Minimum Expectations ==<br />
Situations will be considered and treated on a case by case basis. <br />
<br /><br />
The audit statement needs to clearly indicate which [[CA/Audit_Statements#Audited_Locations|audited locations]] were and were not audited, and whether the inspection at each location was physically carried out in person, and which audit criteria were checked (or not checked) at each location.<br />
<br />
=== ETSI Audits ===<br />
[https://groups.google.com/d/msg/mozilla.dev.security.policy/4Q6WAgLAvDo/zMJu6HWkAQAJ Guidance provided in mozilla.dev.security.policy] included the following: <br />
<br /><br />
If facilities can’t be audited by auditors of the CAB in person, possible alternatives are:<br />
* “Network-assisted auditing techniques” are possible (ETSI EN 319 403, 7.4.1.2) or<br />
* CAB may subcontract auditors that do not fall under the restriction, if they fulfil the auditor requirements. The CAB always remains fully responsible for such outsourced activities. (ISO/IEC 17065, 6.2.2 ).<br />
If such alternatives were accepted by the CAB to provide reasonable assurance with regard to the requirements to be audited, this would result in a normal audit conclusion and would not be visible on an audit attestation letter.<br />
<br />
An ETSI audit shall be performed in any case making sure that everything which reasonably can be audited will be audited - there is especially no restriction to do a full Stage 1 document audit. If facilities cannot be audited by auditors of the CAB in person and the two alternatives stated above are not possible or the CAB does not regard them to provide reasonable assurance with regard to the requirements to be audited in order to draw a reasonable audit conclusion this shall be documented in the audit report.<br />
<br /><br />
In any case an ETSI Audit Attestation Letter (AAL) shall be issued for the required audit period clearly stating in case limitations have been encountered by the auditor: the type of the limitation (e.g. control not audited in person or not audited at all) and description of the limitation (e.g. which controls were not covered in person or not covered at all). <br />
<br /><br /><br />
After audit restrictions have been lifted:<br />
An ETSI audit shall be performed as soon as restrictions have been lifted. It is possible to re-use the original audit results and perform an additional audit just with regard to the non audited requirements (ISO/IEC 17065, 7.4). Usually, the period during which this is possible is limited by the CAB (ACAB’c: 6 month). Once the original audit becomes too old, a completely new audit would be necessary.<br />
Therefore, the ETSI audit shall<br />
* either be focused on the parts not covered throughout the previous audit as stated in the AAL and comprise the same audit period as stated in the last report. In this case an amendment AAL for the original period would to be issued even it is dated more than 3 month after the end of the audit period.<br />
* or comprise the full audit scope of an ETSI audit and the audit period starting with the same begin date as stated in the last report. In this case a new AAL will be issued replacing the previous one and resulting in an extend period of more than 12 month.<br />
Please note: Such an extend period would only be possible, if a new full audit has been performed (covering the time of the original period plus the extension till the last day of the audit).<br />
<br />
For more guidance please refer to www.acab-c.com or send your request to cabforum@acab-c.com.<br />
<br />
=== WebTrust Audits ===<br />
[https://groups.google.com/d/msg/mozilla.dev.security.policy/4Q6WAgLAvDo/K7u11d6xAgAJ Guidance provided in mozilla.dev.security.policy] included the following: <br />
<br /><br />
Ultimately, when an auditor is not able to obtain assurance on the entire scope of the engagement, and realizing a carved out approach is not permitted in a WebTrust audit, for example, when a certain data center is not able to be visited to observe controls operating and underlying documentation, the auditor will not be able to provide an unmodified/unqualified/clean opinion and the client would not be able to display the WebTrust seal. In these situations, the auditor would include an explanatory paragraph that details what gave rise to the scope limitation and issue one of the following modified opinions:<br />
* Qualified opinion (when conditions are least severe but significant enough to mention), stating an except for paragraph explaining the condition(s) arising from the scope limitation, such as not being able to test the data center.<br />
* Adverse opinion (when conditions are more severe), stating that the conditions are such that due to the severity of the scope limitation, the auditor states controls are not operating effectively and they were not able to satisfy themselves that the necessary controls were able to operate.<br />
* Disclaimer of opinion (when conditions are most severe), stating that the auditor is unable to form any opinion due to the nature of the scope limitation.<br />
<br />
If the potential threat of a scope limitation is primarily due to an auditor not being able to travel to perform necessary testing, as with the Coronavirus, there are potential remedies for the auditor to consider, including, but not limited to:<br />
* Using the work of another auditor, whereby the lead auditor verifies the independence, qualifications and technical competency of another firm that can do a portion of the work, and the lead auditor directs the work, plans, supervises and reviews the other auditor’s work, taking ultimate responsibility. In this case, no mention of the other firm is made in the report as the lead auditor is taking responsibility for the other firm’s work.<br />
* Using technology to observe physical controls and underlying documents/artifacts via remote means, such as video. In this case, the auditor must ensure the authenticity, integrity, security and confidentiality of the transmission.<br />
<br />
= Auditor Qualifications =<br />
<br />
Section [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#32-auditors 3.2 of Mozilla's Root Store Policy] says: "Mozilla requires that audits MUST be performed by a Qualified Auditor, as defined in the Baseline Requirements section 8.2."<br />
<br />
Section 8.2 of the [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements] says:<br />
The CA’s audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills:<br />
# Independence from the subject of the audit;<br />
# The ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme (see Section 8.1);<br />
# Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function;<br />
# (For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with ISO/IEC 17065 applying the requirements specified in ETSI EN 319 403; <br />
# (For audits conducted in accordance with the WebTrust standard) licensed by WebTrust;<br />
# Bound by law, government regulation, or professional code of ethics; and<br />
# Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage.<br />
<br />
== Providing Auditor Qualifications ==<br />
<br /><br />
Version 2.7.1 of Mozilla's Root Store Policy requires CAs to have their auditor provide information about the auditor's qualifications when they provide audit statements. The information needs to be sufficient for us to see that the requirements listed above have been met by the audit team, but does not need to specifically name the individuals on the team, other than the lead auditor who signs the audit statement. The Audit Team may consist of one person provided that the person meets all criteria set out above and that there is an audit quality reviewer. <br />
<br />
CAs must submit a summary of the Audit Team's qualifications and experience, as outlined below with respect to the audit. The information can also be provided as part of the audit result documentation, like the [https://www.acab-c.com/downloads/ ETSI Audit Attestation Letter (AAL)], or as a supplement to the WebTrust Assurance Report.<br />
<br />
* Date that the audit report was signed<br />
* Full name of the CA that was audited<br />
* Name and address of the audit firm or Conformity Assessment Body (CAB)<br />
* Audit Criteria, e.g. ETSI / WebTrust<br />
* Proof of audit firm or CAB Accreditation (URL), see paragraphs below. <br />
* Name of Lead Auditor (except where prohibited by law or other public policy, in which case, we ask that you not provide any personally identifiable information)<br />
* For the Audit Team and the Audit Quality Reviewer, qualification information such as:<br />
** Number of Audit Team Members<br />
** Academic qualifications or professional training received<br />
** Average Years of Auditing Experience auditing trust services or similar information systems <br />
** Experience, Special Skills, and Qualifications (e.g. audit/assessment principles and functions, information technology, software development, trust services, public key infrastructure, CA operations, and information security including risk assessment/management, network security, physical security, etc.)<br />
** Credentials, Designations, or Certifications (e.g. CPA, CISA, CITP, CISSP, CCSP/CCA/CCP, etc.)<br />
* How the Audit Team and team members are bound by law, regulation or professional standards to render an independent assessment of the CA (e.g.https://pub.aicpa.org/codeofconduct/Ethics.aspx# 0.300.050 Objectivity and Independence; CPA Canada, Rule 204; or Annex A of ETSI EN 319 403/403-1, respectively)<br />
* Whether the Audit Team relied on any third-party specialists or affiliate audit firms, and if so, their names and where they performed services.<br />
<br />
== Verifying WebTrust Auditor Qualifications ==<br />
For WebTrust auditors, a representative of Mozilla confirms that the auditor's name and country are listed in [https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international CPA Canada's Licensed WebTrust practitioners web page]. <br />
<br />
Send email to webtrust@cpacanada.ca for more information about this list or about the process to become a licensed WebTrust practitioner.<br />
<br />
== Verifying ETSI Auditor Qualifications ==<br />
For ETSI auditors, a representative of Mozilla confirms that the auditor's name and [https://european-accreditation.org/ea-%20members/directory-of-ea-members-and-mla-signatories/ Accreditation Attestation] are listed in the [https://www.acab-c.com/members/ ACAB'c CAB-member List]. <br />
<br />
Send email to secretary@acab-c.org for more information about this list or about the process to become a accredited auditor for Trust Services under the EU eIDAS scheme following ETSI normative requirements as applicable to serve the [https://cabforum.org/ CA/B Forum] ecosystem and the [https://www.mozilla.org/projects/security/certs/policy/ Mozilla Browser Root Store Policy].<br />
<br /><br />
<br />
'''Comprehensive Check'''<br /><br />
<br />
The following additional check is only needed if the auditor's name and Accreditation Attestation are not listed in the [https://www.acab-c.com/members/ ACAB'c CAB-member List]. <br />
* Require the ETSI auditor to provide a comprehensive written explanation about why they are not listed in not listed in the [https://www.acab-c.com/members/ ACAB'c CAB-member List].<br />
* The auditor must provide a rationale clearly referring back to all of the following:<br />
** European Accreditation to demonstrate they act under the EU accreditation scheme,<br />
** ISO/IEC 17065 plus ETSI EN 319 403-1 to demonstrate they are accredited/allowed to audit publicly trusted CA/Trust Service Provider according to<br />
*** ETSI EN 319 401 and ETSI EN 319 411-1 and<br />
*** ETSI EN 319 411-2 for QWACS certificates according to the EU eIDAS Regulation 910/2014.<br />
* Review the documents and explanation.<br />
* Request external review from ACAB’c to provide opinion about the CAB's accreditation.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1249320CA/Vulnerability Disclosure2024-01-04T21:01:00Z<p>Bwilson: /* Markdown Template */ Clarified contact information</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents in Bugzilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report] for non-compliances, as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
Ensure that you report security incidents to other root stores as well. Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla. (People cc:'ed in the bug have access to view the bug, so review the cc: list to ensure that no unintended people are in that list.)<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Serious vulnerabilities''' include critical software and web application vulnerabilities, faulty APIs that could lead to data breaches, zero-day exploits, and malware infections.<br />
<br />
'''Security Incidents''' include the following:<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Ransomware attacks, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability/Incident Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the nature of the compromise, the specific systems, infrastructure, or processes affected, the duration of the vulnerability/incident, and the identity of any threat actors. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report].<br />
<br />
==== Severity/Impact Assessment ====<br />
See '''"Determining Significance"''' above. <br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on subscribers, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services.<br />
# Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
# Detail any other mitigation steps or "action items" being taken to mitigate the effects of the vulnerabilities/incident, including the type of action (e.g. patching, access control, training, etc.), the status of each action, and the date each action will be completed.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
# Outline the remediation plan and summarize the actions to be taken to address the incident, root cause(s), or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation action items that you are taking to resolve the current situation, to address the root cause(s), and to ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, the type of action (e.g. governance review, enhanced alerting, training, documentation, etc.), its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information (e.g. email address or group distribution list) for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.<br />
<br />
== Markdown Template ==<br />
<pre><br />
## Vulnerability/Incident Disclosure Form<br />
<br />
### Concise Summary<br />
<br />
### Vulnerability/Incident Details<br />
#### Timeline<br />
All times are UTC.<br />
<br />
YYYY-MM-DD:<br />
- HH:MM Example<br />
- <br />
#### Type and Detailed Description<br />
Nature of the compromise:<br />
Specific systems, infrastructure, or processes affected:<br />
Duration:<br />
Identity of threat actors:<br />
<br />
<br />
#### Root Cause(s)<br />
<br />
### Severity/Impact Assessment<br />
#### Potential Impact on CA operations, systems, certificate trustworthiness<br />
<br />
#### Number and type(s) of certificates affected (if any)<br />
<br />
#### Potential impact on subscribers, relying parties, and others<br />
<br />
#### Escalation Potential<br />
<br />
### Response and Mitigation<br />
#### Recommended Actions for Root Store(s)<br />
<br />
#### Immediate Actions Taken to Contain/Mitigate<br />
<br />
#### Collaboration with Forensics, CSIRTS, LEAs, etc.<br />
<br />
#### Mitigation Steps Being Taken<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- |-------- |<br />
| Example | Patching | 2024-01-19 | 50% complete |<br />
<br />
<br />
### Remediation Plan<br />
<br />
#### Outline/Summary of Remediation Plan<br />
<br />
#### Remediation Action Items<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- | -------- |<br />
| Example | Governance Review | 2024-01-19 | 50% complete |<br />
<br />
#### Additional Measures<br />
<br />
### Contact Information<br />
<br />
Email Address<br />
</pre></div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1249319CA/Vulnerability Disclosure2024-01-04T20:59:25Z<p>Bwilson: /* Contact Information */ Clarified</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents in Bugzilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report] for non-compliances, as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
Ensure that you report security incidents to other root stores as well. Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla. (People cc:'ed in the bug have access to view the bug, so review the cc: list to ensure that no unintended people are in that list.)<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Serious vulnerabilities''' include critical software and web application vulnerabilities, faulty APIs that could lead to data breaches, zero-day exploits, and malware infections.<br />
<br />
'''Security Incidents''' include the following:<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Ransomware attacks, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability/Incident Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the nature of the compromise, the specific systems, infrastructure, or processes affected, the duration of the vulnerability/incident, and the identity of any threat actors. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report].<br />
<br />
==== Severity/Impact Assessment ====<br />
See '''"Determining Significance"''' above. <br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on subscribers, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services.<br />
# Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
# Detail any other mitigation steps or "action items" being taken to mitigate the effects of the vulnerabilities/incident, including the type of action (e.g. patching, access control, training, etc.), the status of each action, and the date each action will be completed.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
# Outline the remediation plan and summarize the actions to be taken to address the incident, root cause(s), or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation action items that you are taking to resolve the current situation, to address the root cause(s), and to ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, the type of action (e.g. governance review, enhanced alerting, training, documentation, etc.), its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information (e.g. email address or group distribution list) for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.<br />
<br />
== Markdown Template ==<br />
<pre><br />
## Vulnerability/Incident Disclosure Form<br />
<br />
### Concise Summary<br />
<br />
### Vulnerability/Incident Details<br />
#### Timeline<br />
All times are UTC.<br />
<br />
YYYY-MM-DD:<br />
- HH:MM Example<br />
- <br />
#### Type and Detailed Description<br />
Nature of the compromise:<br />
Specific systems, infrastructure, or processes affected:<br />
Duration:<br />
Identity of threat actors:<br />
<br />
<br />
#### Root Cause(s)<br />
<br />
### Severity/Impact Assessment<br />
#### Potential Impact on CA operations, systems, certificate trustworthiness<br />
<br />
#### Number and type(s) of certificates affected (if any)<br />
<br />
#### Potential impact on subscribers, relying parties, and others<br />
<br />
#### Escalation Potential<br />
<br />
### Response and Mitigation<br />
#### Recommended Actions for Root Store(s)<br />
<br />
#### Immediate Actions Taken to Contain/Mitigate<br />
<br />
#### Collaboration with Forensics, CSIRTS, LEAs, etc.<br />
<br />
#### Mitigation Steps Being Taken<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- |-------- |<br />
| Example | Patching | 2024-01-19 | 50% complete |<br />
<br />
<br />
### Remediation Plan<br />
<br />
#### Outline/Summary of Remediation Plan<br />
<br />
#### Remediation Action Items<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- | -------- |<br />
| Example | Governance Review | 2024-01-19 | 50% complete |<br />
<br />
#### Additional Measures<br />
<br />
### Contact Information<br />
</pre></div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Transition_SMIME_BRs&diff=1249313CA/Transition SMIME BRs2024-01-03T23:28:45Z<p>Bwilson: /* Audit Migration Plan */ Updated Webtrust SMIME Criteria URL</p>
<hr />
<div>The CA/Browser Forum "Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates" ("S/MIME Baseline Requirements") introduces several new requirements for CAs capable of issuing working email certificates. The purpose of this page is to provide guidance for CAs transitioning toward compliance with the S/MIME Baseline Requirements.<br />
<br />
== Audit Migration Plan ==<br />
<br />
Effective September 1, 2023, Certification Authorities (CAs) must follow the CA/Browser Forum’s Baseline Requirements for S/MIME Certificates ([https://cabforum.org/smime-br/ S/MIME BRs]). <br />
<br />
A CA operator’s CP or CPS must state that it complies with the current version of the S/MIME BRs. <br />
<br />
[https://www.cpacanada.ca/-/media/site/operational/ms-member-services/docs/webtrust/smime-certificates_101_final_aoda-compliant.pdf WebTrust audit criteria] and [https://www.etsi.org/deliver/etsi_ts/119400_119499/11941106/01.01.01_60/ts_11941106v010101p.pdf ETSI audit criteria] are already in place for the S/MIME BRs.<br />
<br />
CA root certificates and subordinate CA certificates that are technically capable of issuing S/MIME certificates that chain up (either directly or transitively) to a root certificate that has the email (S/MIME) trust bit enabled in Mozilla's CA Certificate Program shall be audited with Period-of-Time audits according to the S/MIME BRs between October 30, 2023, and October 29, 2024, and annually thereafter. <br />
<br />
CA operators that already have an email-trust-bit-enabled CA certificate in the root store may maintain their current annual audit cycles and provide the new S/MIME BR audits when they provide their other annual audit reports, even if they are in the process of requesting inclusion of one or more new, email-trust-bit-enabled root CA certificates. For instance, if a CA operator typically provides audit reports in July 2024 and is requesting the inclusion of a new email-bit-enabled root CA, the corresponding S/MIME BR audit encompassing both existing and new email-trust-bit-enabled root CA certificates can be submitted during the annual audit submission in July 2024.<br />
<br />
For any new CA operator requesting inclusion of root CA certificate after October 30, 2023, must be audited according to the S/MIME BRs if the email trust bit is to be enabled.<br />
<br />
In most cases, the audit period start date for the first S/MIME BR audit will be September 1, 2023.<br />
* CA operators should modify their CP or CPS on or before September 1, 2023, to assert compliance with the S/MIME BRs.<br />
* The first S/MIME BR audit report should include September 1, 2023, until the regularly-scheduled end of the CA's audit period.<br />
** If the CA operator’s existing regular audit period for other audit types ends after October 30, 2023, then we will expect to receive an S/MIME BR audit that covers September 1, 2023, through the end of that audit period (i.e. a Period-of-Time audit). <br />
<br />
* The first S/MIME BR audit for each CA root certificate and subordinate CA certificate may include a reasonable list of non-compliances that the CA operator (or subordinate CA operator) is not yet in compliance with.<br />
** Major non-compliances should be reported in Bugzilla and corrected as soon as possible<br />
** Only one Incident Bug needs to be filed containing the list of the non-compliances in a CA operator’s first S/MIME BR audit.<br />
<br />
* Submission of a CA's S/MIME BR audit report during the second year is expected to confirm that the issues that were listed in the first S/MIME BR audit report have been resolved.<br />
<br />
== Re-Issuance of Existing Intermediate CA Certificates for S/MIME ==<br />
<br />
Section 3.1.3 of Mozilla Root Store Policy requires that all CA keys have the appropriate cradle-to-grave key protection audit reports. However, many existing Intermediate Certificates in the S/MIME ecosystem today were created prior to the establishment of this requirement. In order to facilitate the transition of email certificate-issuing Intermediate CAs to the profile specified in the S/MIME Baseline Requirements, the re-issuance of an existing Intermediate CA Certificate that fulfills all the following requirements (even in the absence of audit reports from key creation) is permitted:<br />
<br />
# The original Intermediate Certificate directly or transitively chains to a Root Certificate with the email trust bit enabled in the Mozilla Root Program;<br />
# The original Intermediate Certificate has been audited in accordance with section 3.1.3 and has appeared on the CA Operator's latest audit report;<br />
# The original Intermediate Certificate includes no Extended Key Usage extension, contains anyExtendedKeyUsage in the Extended Key Usage extension, or contains id-kp-emailProtection in the Extended Key Usage extension; and<br />
# The original Intermediate Certificate complies with the profile defined in RFC 5280. The following two deviations from the RFC 5280 profile are acceptable: (a) The original Intermediate Certificate contains a Name Constraints extension that is not marked critical; and/or (b) The original Intermediate Certificate contains a policy qualifier of type UserNotice which contains explicitText that uses an encoding that is not permitted by RFC 5280 (i.e., the DisplayText is encoded using BMPString or VisibleString).<br />
<br />
If any of the above requirements are not satisfied by the original Intermediate Certificate, then the CA Organization SHALL NOT re-issue the Intermediate Certificate.<br />
<br />
If all of the above requirements are met, then the Intermediate Certificate MAY be re-issued, subject to the following requirements:<br />
<br />
# The original and re-issued Intermediate Certificate contain the same Subject Distinguished Name and certify the same key;<br />
# The notAfter field value of the re-issued Intermediate Certificate is less than or equal to the value of the notAfter field of the original Intermediate Certificate; <br />
# The re-issued Intermediate Certificate contains at least one of the following policy identifier types in the Certificate Policies extension: (a) anyPolicy; and/or (b) one or more of the CA/Browser Forum policy OIDs as defined in section 7.1.6.1 of the S/MIME Baseline Requirements. (Additional policy identifiers MAY be present.); and<br />
# The re-issued Intermediate Certificate complies with the profile for S/MIME Intermediate Certificates as defined in section 7 of the S/MIME Baseline Requirements.<br />
<br />
If any of the above requirements are not satisfied by the profile of the re-issued Intermediate Certificate, then the CA Organization SHALL NOT re-issue the Intermediate Certificate.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Transition_SMIME_BRs&diff=1249312CA/Transition SMIME BRs2024-01-03T23:26:13Z<p>Bwilson: /* Audit Migration Plan */ Made edits as proposed</p>
<hr />
<div>The CA/Browser Forum "Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates" ("S/MIME Baseline Requirements") introduces several new requirements for CAs capable of issuing working email certificates. The purpose of this page is to provide guidance for CAs transitioning toward compliance with the S/MIME Baseline Requirements.<br />
<br />
== Audit Migration Plan ==<br />
<br />
Effective September 1, 2023, Certification Authorities (CAs) must follow the CA/Browser Forum’s Baseline Requirements for S/MIME Certificates ([https://cabforum.org/smime-br/ S/MIME BRs]). <br />
<br />
A CA operator’s CP or CPS must state that it complies with the current version of the S/MIME BRs. <br />
<br />
[https://www.cpacanada.ca/-/media/site/operational/ms-member-services/docs/webtrust/01618_ms_smime-certificates_final_aoda-compliant.pdf WebTrust audit criteria] and [https://www.etsi.org/deliver/etsi_ts/119400_119499/11941106/01.01.01_60/ts_11941106v010101p.pdf ETSI audit criteria] are already in place for the S/MIME BRs.<br />
<br />
CA root certificates and subordinate CA certificates that are technically capable of issuing S/MIME certificates that chain up (either directly or transitively) to a root certificate that has the email (S/MIME) trust bit enabled in Mozilla's CA Certificate Program shall be audited with Period-of-Time audits according to the S/MIME BRs between October 30, 2023, and October 29, 2024, and annually thereafter. <br />
<br />
CA operators that already have an email-trust-bit-enabled CA certificate in the root store may maintain their current annual audit cycles and provide the new S/MIME BR audits when they provide their other annual audit reports, even if they are in the process of requesting inclusion of one or more new, email-trust-bit-enabled root CA certificates. For instance, if a CA operator typically provides audit reports in July 2024 and is requesting the inclusion of a new email-bit-enabled root CA, the corresponding S/MIME BR audit encompassing both existing and new email-trust-bit-enabled root CA certificates can be submitted during the annual audit submission in July 2024.<br />
<br />
For any new CA operator requesting inclusion of root CA certificate after October 30, 2023, must be audited according to the S/MIME BRs if the email trust bit is to be enabled.<br />
<br />
In most cases, the audit period start date for the first S/MIME BR audit will be September 1, 2023.<br />
* CA operators should modify their CP or CPS on or before September 1, 2023, to assert compliance with the S/MIME BRs.<br />
* The first S/MIME BR audit report should include September 1, 2023, until the regularly-scheduled end of the CA's audit period.<br />
** If the CA operator’s existing regular audit period for other audit types ends after October 30, 2023, then we will expect to receive an S/MIME BR audit that covers September 1, 2023, through the end of that audit period (i.e. a Period-of-Time audit). <br />
<br />
* The first S/MIME BR audit for each CA root certificate and subordinate CA certificate may include a reasonable list of non-compliances that the CA operator (or subordinate CA operator) is not yet in compliance with.<br />
** Major non-compliances should be reported in Bugzilla and corrected as soon as possible<br />
** Only one Incident Bug needs to be filed containing the list of the non-compliances in a CA operator’s first S/MIME BR audit.<br />
<br />
* Submission of a CA's S/MIME BR audit report during the second year is expected to confirm that the issues that were listed in the first S/MIME BR audit report have been resolved.<br />
<br />
== Re-Issuance of Existing Intermediate CA Certificates for S/MIME ==<br />
<br />
Section 3.1.3 of Mozilla Root Store Policy requires that all CA keys have the appropriate cradle-to-grave key protection audit reports. However, many existing Intermediate Certificates in the S/MIME ecosystem today were created prior to the establishment of this requirement. In order to facilitate the transition of email certificate-issuing Intermediate CAs to the profile specified in the S/MIME Baseline Requirements, the re-issuance of an existing Intermediate CA Certificate that fulfills all the following requirements (even in the absence of audit reports from key creation) is permitted:<br />
<br />
# The original Intermediate Certificate directly or transitively chains to a Root Certificate with the email trust bit enabled in the Mozilla Root Program;<br />
# The original Intermediate Certificate has been audited in accordance with section 3.1.3 and has appeared on the CA Operator's latest audit report;<br />
# The original Intermediate Certificate includes no Extended Key Usage extension, contains anyExtendedKeyUsage in the Extended Key Usage extension, or contains id-kp-emailProtection in the Extended Key Usage extension; and<br />
# The original Intermediate Certificate complies with the profile defined in RFC 5280. The following two deviations from the RFC 5280 profile are acceptable: (a) The original Intermediate Certificate contains a Name Constraints extension that is not marked critical; and/or (b) The original Intermediate Certificate contains a policy qualifier of type UserNotice which contains explicitText that uses an encoding that is not permitted by RFC 5280 (i.e., the DisplayText is encoded using BMPString or VisibleString).<br />
<br />
If any of the above requirements are not satisfied by the original Intermediate Certificate, then the CA Organization SHALL NOT re-issue the Intermediate Certificate.<br />
<br />
If all of the above requirements are met, then the Intermediate Certificate MAY be re-issued, subject to the following requirements:<br />
<br />
# The original and re-issued Intermediate Certificate contain the same Subject Distinguished Name and certify the same key;<br />
# The notAfter field value of the re-issued Intermediate Certificate is less than or equal to the value of the notAfter field of the original Intermediate Certificate; <br />
# The re-issued Intermediate Certificate contains at least one of the following policy identifier types in the Certificate Policies extension: (a) anyPolicy; and/or (b) one or more of the CA/Browser Forum policy OIDs as defined in section 7.1.6.1 of the S/MIME Baseline Requirements. (Additional policy identifiers MAY be present.); and<br />
# The re-issued Intermediate Certificate complies with the profile for S/MIME Intermediate Certificates as defined in section 7 of the S/MIME Baseline Requirements.<br />
<br />
If any of the above requirements are not satisfied by the profile of the re-issued Intermediate Certificate, then the CA Organization SHALL NOT re-issue the Intermediate Certificate.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1249304NSS:Release Versions2024-01-02T17:58:14Z<p>Bwilson: /* Future Releases */ Added rows</p>
<hr />
<div>* '''NSS Release Bug (meta)''' https://bugzilla.mozilla.org/show_bug.cgi?id=1816499<br />
* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
! Release Manager<br />
|-<br />
| 3.97<br />
|<br />
|<br />
| 2024-01-04<br />
| '''2024-01-11'''<br />
| 2024-01-22<br />
| 123<br />
| 2024-02-20<br />
| B. Beurdouche<br />
|-<br />
| 3.98<br />
|<br />
|<br />
| 2024-03-XX<br />
| '''2024-02-15'''<br />
| 2024-02-19<br />
| 124<br />
| 2024-03-19<br />
| Anna<br />
|-<br />
| 3.99<br />
|<br />
|<br />
| 2024-XX<br />
| '''2024-03-14'''<br />
| 2024-03-18<br />
| 125<br />
| 2024-04-16<br />
| John<br />
|-<br />
| 3.100<br />
|<br />
|<br />
| 2024-XX<br />
| '''2024-04-11'''<br />
| 2024-04-15<br />
| 126<br />
| 2024-05-14<br />
| B. Beurdouche<br />
|-<br />
}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| New NSPR version<br />
| New CA list version<br />
| NSS Beta<br />
| NSS Release<br />
| Firefox merge date<br />
| Firefox version<br />
| Firefox release date<br />
| Release Manager<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.96<br />
|<br />
|<br />
| 2023-12-07<br />
| '''2023-12-14'''<br />
| 2023-12-18<br />
| 122<br />
| 2024-01-23<br />
|-<br />
| 3.95<br />
|<br />
|2.64<br />
| 2023-11-09<br />
| '''2023-11-16'''<br />
| 2023-11-20<br />
| 121<br />
| 2023-12-19<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-09-14<br />
| '''2023-09-21'''<br />
| 2023-09-25<br />
| 119<br />
| 2023-10-24<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-08-18<br />
| '''2023-08-23'''<br />
| 2023-08-25<br />
| 118<br />
| 2023-09-26<br />
|-<br />
| 3.92<br />
|<br />
| 2.62<br />
| 2023-07-12<br />
| '''2023-07-19'''<br />
| 2023-07-27<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.91 <br />(ESR)<br />
|<br />
|<br />
| 2023-06-19<br />
| '''2023-06-26'''<br />
| 2023-06-29<br />
| 116<br />
| 2023-07-04<br />
|-<br />
| Skipped<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<tr><br />
<td>3.94</td> <td><b>{{bug|1842932}}</b>: {{bug|1842935}}, {{bug|1850598}}, {{bug|1850982}}, {{bug|1851044}}, {{bug|1851049}}, {{bug|1855318}}, {{bug|1860670}} </td> <td>121</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
, , , , , , <br />
<tr><br />
<td>3.92</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/CPS_Review&diff=1249253CA/CPS Review2023-12-19T17:57:45Z<p>Bwilson: Added Firmaprofesional and dates</p>
<hr />
<div><br />
Here are previous reviews of CP/CPS documents:<br />
<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9369465 Review of Firmaprofesional's CP and CPS (XLS) 2023-12-19]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9366027 Review of PostSignum's CP (XLS) 2023-12-12]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9357960 Review of Commscope's CP/CPS (XLS) 2023-10-11]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9342057 Review of TrustAsia's CP/CPS (XLS) 2023-07-06]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9328642 Review of Sectigo's CPS (XLS) 2023-04-14]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9328039 Review of Cybertrust Japan's CPS (XLS) 2023-04-19]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9327554 Review of SSL.com's CP/CPS 2023-04-21 (XLS)]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9326434 Review of ATOS Trustcenter's CPS 2023-04-01 (XLS)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1647181#c24 Second Review of BJCA's CPS]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9284758 Review of Fina's CPS and Compliance Self Assessment (XLS)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1431811#c14 Review of Notarius' CPS (email-only)] <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1592138#c8 Review of Macao Post eSignTrust CPS (email-only)] <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1694421#c17 Review of DigitalSign's CPS (email-only)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1710831#c16 Review of LAWtrust's CPS (email-only)] <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1677631#c73 Comments to SERPRO's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1727941#c11 Review of Certainly's CP/CPS] [https://bugzilla.mozilla.org/attachment.cgi?id=9270636 (Download full review in XLS attachment)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1313982#c41 Review of SECOM's CPs and CPSes] <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1628720#c19 Second review of eTugra's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1628720#c16 BR and EV Review on eTugra's CPS] [https://bugzilla.mozilla.org/attachment.cgi?id=9254979 (Download full review in XLS attachment)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1706228#c9 BR and EV Review on DigiCert's CP/CPS] [https://bugzilla.mozilla.org/attachment.cgi?id=9252944 (Download full review in XLS attachment)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1679258#c9 BR and EV Review on D-TRUST's CP/CPS] [https://bugzilla.mozilla.org/attachment.cgi?id=9243128 (Download full review in XLS attachment)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c50 Detailed Extended Validation Review Feedback to iTrusChina on EV aspects of CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1454977#c75 Second Review on ACIN - Global Trusted Sign's CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1664161#c6 Detailed BR Review Feedback to Telia on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1705904#c20 BR Review of KIR's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1454977#c52 Detailed BR and EV Review Feedback to ACIN - Global Trusted Sign]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1102143#c38 Detailed BR and EV Review Feedback on Firmaprofesional's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1563417#c19 Detailed BR and EV Review Feedback on Chunghwa Telecom's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1695487#c6 Detailed BR Review Feedback to HARICA on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1701317#c6 Detailed Review Feedback to ISRG/Let's Encrypt on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1690054#c8 Detailed Extended Validation Review Feedback to HARICA on EV aspects of CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1493679#c25 Detailed BR and EV Review Feedback to Network Solutions on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1627552#c13 Detailed BR and EV Review Feedback to GLOBALTRUST2020 on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1647181#c7 Detailed BR and EV Review Feedback to Beijing CA on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1579454#c9 Detailed Extended Validation Review Feedback to NetLock on EV aspects of CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1587779#c12 Detailed Review Feedback to TunTrust on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1585951#c36 Detailed Review Feedback to ANF on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1558450#c17 Detailed Review Feedback to Digidentity on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c30 Detailed Review Feedback to iTrusChina on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29 Detailed Review Feedback to NAVER Group on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1563417#c7 Detailed Review Feedback to Chunghwa Telecom on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1532426#c31 Initial Review Feedback to SSLCOM Group on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551703#c6 Detailed Review Feedback to Identrust on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1528369#c10 Detailed Review Feedback to SecureTrust]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1479040#c42 Detailed Review Feedback to Certisign]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ Detailed Review Feedback on Microsec]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1102143#c25 Detailed Review Feedback on Firmaprofesional]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c13 Detailed Review Feedback on certSIGN CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1474556#c16 Detailed Review Feedback on Dubai Government CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1448093#c56 Detailed Review Feedback on Microsoft CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1480510#c10 Detailed Review Feedback on Entrust CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1464306#c29 Detailed Review Feedback on Hongkong Post CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1442337#c37 Detailed Review Feedback on eMudhra CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1309797#c72 Detailed Review feedback on SHECA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1325532#c41 Detailed Review Feedback on Google Trust Services]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1390803#c14 Detailed Review Feedback on GlobalSign]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/36t-jbTQnTY/nwkFyzobAgAJ Review Feedback on WISeKey]<br />
** That was after [https://bugzilla.mozilla.org/show_bug.cgi?id=1403591#c17 blocking problems with the CP/CPS] were resolved.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/skev4gp_bY4/snIuP2JLAgAJ Review Feedback on Camerfirma]<br />
** CA may submit new root inclusion request for newly generated root that is fully compliant with Mozilla's Root Store Policy and the BRs.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/R2uG3wisU7s/ie_v7RHMBwAJ Review Feedback on TrustCor]<br />
** CP and CPS documents clear, well written, and they provided sufficient detail to assess the policies in place. <br />
* Review Feedback on Kamu SM (Government of Turkey)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/EtJpw8r7uGs/NmOfjdKIAwAJ CPS document clear and well written]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/vjXyml8Hy-E/bhxftrNkEAAJ New requirements for Domain Validation] -- all CAs must update their CP/CPS according to section 3.2.2.4 of [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf version 1.4.1 of the BRs].<br />
* Review Feedback on Guangdong Certificate Authority (GDCA)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/YVOKPfnSAQAJ English translations of documents MUST match the original document.]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/blMVMaHlAwAJ CA is responsible for providing accurate translation.]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/zZ5RHXCkpGM/dvx0DjswBgAJ Review Feedback on Amazon Trust Services' CP/CPS]<br />
** Amazon was commended for the clarity of their CP and CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/eHC0JDQwBgAJ Review Feedback on Japan GPKI's CP/CPS]<br />
** Japan GPKI's CP/CPS did not contain sufficient detail, so discussion put on hold pending updated CP/CPS.<br />
* A-Trust discussion [https://groups.google.com/d/msg/mozilla.dev.security.policy/Q1beEDFdzxg/6ZILykF0AgAJ put on hold pending translation of CP/CPS into English].<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/bGWV7_lwBAAJ Review Feedback on ComSign's CP/CPS]<br />
** ComSign's discussion was put on hold until the CP/CPS is updated to conform to either RFC 2527 or RFC 3647, as required by the Baseline Requirements. And be translated into English.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ Review Feedback on SSC's CP/CPS]<br />
** SSC's discussion was put on hold pending updated CP/CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/gKCqWRmBQ_8/A1eI_zsoAAAJ Review Feedback on ISRG's CP/CPS]<br />
** ISRG's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/z1rc7vUSlb0/wJkwv5x3AgAJ Review Feedback on DocuSign's CP/CPS]<br />
** DocuSign's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/dYoQcI0e1qA/ucp1cHfVAAAJ Review Feedback on HARICA's CP/CPS]<br />
** HARICA's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ Review Feedback on LuxTrust's CP/CPS]<br />
** The concerns raised regarding LuxTrust's CP/CPS resulted in the inclusion request being put on hold until the CP/CPS was updated.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/Xvmolz36PsEJ Review Feedback on Krajowa Izba Rozliczeniowa (KIR) CP/CPS]<br />
** KIR updated their CP/CPS according to the [https://groups.google.com/d/msg/mozilla.dev.security.policy/aNbK4zw_Zb8/wmwnbVbLb8cJ review feedback provided in their first discussion] <br />
** Then had to update their CP/CPS again due to feedback in their second discussion.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/CPS_Review&diff=1249203CA/CPS Review2023-12-12T18:05:48Z<p>Bwilson: Added link to review of PostSignum's CP Review</p>
<hr />
<div><br />
Here are previous reviews of CP/CPS documents:<br />
<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9366027 Review of PostSignum's CP (XLS)]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9357960 Review of Commscope's CP/CPS (XLS)]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9342057 Review of TrustAsia's CP/CPS (XLS)]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9328642 Review of Sectigo's CPS (XLS)]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9328039 Review of Cybertrust Japan's CPS (XLS)]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9327554 Review of SSL.com's CP/CPS (XLS)]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9326434 Review of ATOS Trustcenter's CPS (XLS)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1647181#c24 Second Review of BJCA's CPS]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9284758 Review of Fina's CPS and Compliance Self Assessment (XLS)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1431811#c14 Review of Notarius' CPS (email-only)] <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1592138#c8 Review of Macao Post eSignTrust CPS (email-only)] <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1694421#c17 Review of DigitalSign's CPS (email-only)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1710831#c16 Review of LAWtrust's CPS (email-only)] <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1677631#c73 Comments to SERPRO's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1727941#c11 Review of Certainly's CP/CPS] [https://bugzilla.mozilla.org/attachment.cgi?id=9270636 (Download full review in XLS attachment)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1313982#c41 Review of SECOM's CPs and CPSes] <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1628720#c19 Second review of eTugra's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1628720#c16 BR and EV Review on eTugra's CPS] [https://bugzilla.mozilla.org/attachment.cgi?id=9254979 (Download full review in XLS attachment)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1706228#c9 BR and EV Review on DigiCert's CP/CPS] [https://bugzilla.mozilla.org/attachment.cgi?id=9252944 (Download full review in XLS attachment)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1679258#c9 BR and EV Review on D-TRUST's CP/CPS] [https://bugzilla.mozilla.org/attachment.cgi?id=9243128 (Download full review in XLS attachment)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c50 Detailed Extended Validation Review Feedback to iTrusChina on EV aspects of CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1454977#c75 Second Review on ACIN - Global Trusted Sign's CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1664161#c6 Detailed BR Review Feedback to Telia on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1705904#c20 BR Review of KIR's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1454977#c52 Detailed BR and EV Review Feedback to ACIN - Global Trusted Sign]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1102143#c38 Detailed BR and EV Review Feedback on Firmaprofesional's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1563417#c19 Detailed BR and EV Review Feedback on Chunghwa Telecom's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1695487#c6 Detailed BR Review Feedback to HARICA on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1701317#c6 Detailed Review Feedback to ISRG/Let's Encrypt on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1690054#c8 Detailed Extended Validation Review Feedback to HARICA on EV aspects of CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1493679#c25 Detailed BR and EV Review Feedback to Network Solutions on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1627552#c13 Detailed BR and EV Review Feedback to GLOBALTRUST2020 on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1647181#c7 Detailed BR and EV Review Feedback to Beijing CA on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1579454#c9 Detailed Extended Validation Review Feedback to NetLock on EV aspects of CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1587779#c12 Detailed Review Feedback to TunTrust on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1585951#c36 Detailed Review Feedback to ANF on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1558450#c17 Detailed Review Feedback to Digidentity on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c30 Detailed Review Feedback to iTrusChina on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29 Detailed Review Feedback to NAVER Group on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1563417#c7 Detailed Review Feedback to Chunghwa Telecom on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1532426#c31 Initial Review Feedback to SSLCOM Group on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551703#c6 Detailed Review Feedback to Identrust on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1528369#c10 Detailed Review Feedback to SecureTrust]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1479040#c42 Detailed Review Feedback to Certisign]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ Detailed Review Feedback on Microsec]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1102143#c25 Detailed Review Feedback on Firmaprofesional]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c13 Detailed Review Feedback on certSIGN CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1474556#c16 Detailed Review Feedback on Dubai Government CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1448093#c56 Detailed Review Feedback on Microsoft CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1480510#c10 Detailed Review Feedback on Entrust CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1464306#c29 Detailed Review Feedback on Hongkong Post CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1442337#c37 Detailed Review Feedback on eMudhra CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1309797#c72 Detailed Review feedback on SHECA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1325532#c41 Detailed Review Feedback on Google Trust Services]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1390803#c14 Detailed Review Feedback on GlobalSign]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/36t-jbTQnTY/nwkFyzobAgAJ Review Feedback on WISeKey]<br />
** That was after [https://bugzilla.mozilla.org/show_bug.cgi?id=1403591#c17 blocking problems with the CP/CPS] were resolved.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/skev4gp_bY4/snIuP2JLAgAJ Review Feedback on Camerfirma]<br />
** CA may submit new root inclusion request for newly generated root that is fully compliant with Mozilla's Root Store Policy and the BRs.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/R2uG3wisU7s/ie_v7RHMBwAJ Review Feedback on TrustCor]<br />
** CP and CPS documents clear, well written, and they provided sufficient detail to assess the policies in place. <br />
* Review Feedback on Kamu SM (Government of Turkey)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/EtJpw8r7uGs/NmOfjdKIAwAJ CPS document clear and well written]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/vjXyml8Hy-E/bhxftrNkEAAJ New requirements for Domain Validation] -- all CAs must update their CP/CPS according to section 3.2.2.4 of [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf version 1.4.1 of the BRs].<br />
* Review Feedback on Guangdong Certificate Authority (GDCA)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/YVOKPfnSAQAJ English translations of documents MUST match the original document.]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/blMVMaHlAwAJ CA is responsible for providing accurate translation.]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/zZ5RHXCkpGM/dvx0DjswBgAJ Review Feedback on Amazon Trust Services' CP/CPS]<br />
** Amazon was commended for the clarity of their CP and CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/eHC0JDQwBgAJ Review Feedback on Japan GPKI's CP/CPS]<br />
** Japan GPKI's CP/CPS did not contain sufficient detail, so discussion put on hold pending updated CP/CPS.<br />
* A-Trust discussion [https://groups.google.com/d/msg/mozilla.dev.security.policy/Q1beEDFdzxg/6ZILykF0AgAJ put on hold pending translation of CP/CPS into English].<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/bGWV7_lwBAAJ Review Feedback on ComSign's CP/CPS]<br />
** ComSign's discussion was put on hold until the CP/CPS is updated to conform to either RFC 2527 or RFC 3647, as required by the Baseline Requirements. And be translated into English.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ Review Feedback on SSC's CP/CPS]<br />
** SSC's discussion was put on hold pending updated CP/CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/gKCqWRmBQ_8/A1eI_zsoAAAJ Review Feedback on ISRG's CP/CPS]<br />
** ISRG's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/z1rc7vUSlb0/wJkwv5x3AgAJ Review Feedback on DocuSign's CP/CPS]<br />
** DocuSign's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/dYoQcI0e1qA/ucp1cHfVAAAJ Review Feedback on HARICA's CP/CPS]<br />
** HARICA's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ Review Feedback on LuxTrust's CP/CPS]<br />
** The concerns raised regarding LuxTrust's CP/CPS resulted in the inclusion request being put on hold until the CP/CPS was updated.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/Xvmolz36PsEJ Review Feedback on Krajowa Izba Rozliczeniowa (KIR) CP/CPS]<br />
** KIR updated their CP/CPS according to the [https://groups.google.com/d/msg/mozilla.dev.security.policy/aNbK4zw_Zb8/wmwnbVbLb8cJ review feedback provided in their first discussion] <br />
** Then had to update their CP/CPS again due to feedback in their second discussion.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1249177NSS:Release Versions2023-12-08T22:04:56Z<p>Bwilson: /* Future Releases */ Partially updated into 2024</p>
<hr />
<div>* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
! Release Manager<br />
|-<br />
| 3.96<br />
|<br />
|<br />
| 2023-12-07<br />
| '''2023-12-14'''<br />
| 2023-12-18<br />
| 122<br />
| 2024-01-23<br />
| A. Weine<br />
|-<br />
| 3.97<br />
|<br />
|<br />
| 2024-01-04<br />
| '''2024-01-11'''<br />
| 2024-01-22<br />
| 123<br />
| 2024-02-20<br />
| J. Schanck<br />
|-<br />
| TBD<br />
|<br />
|<br />
| 2024-02-08<br />
| '''2024-02-15'''<br />
| 2024-02-19<br />
| 124<br />
| 2024-03-19<br />
| TBD<br />
|}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| NSPR version<br />
| NSS API freeze date<br />
| <b>NSS Release Date</b><br />
| FF Beta merge date<br />
| Firefox version<br />
| Firefox release date<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.95<br />
|<br />
|2.64<br />
| 2023-11-09<br />
| '''2023-11-16'''<br />
| 2023-11-20<br />
| 121<br />
| 2023-12-19<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-09-14<br />
| '''2023-09-21'''<br />
| 2023-09-25<br />
| 119<br />
| 2023-10-24<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-08-18<br />
| '''2023-08-23'''<br />
| 2023-08-25<br />
| 118<br />
| 2023-09-26<br />
|-<br />
| 3.92<br />
|<br />
| 2.62<br />
| 2023-07-12<br />
| '''2023-07-19'''<br />
| 2023-07-27<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.91 <br />(ESR)<br />
|<br />
|<br />
| 2023-06-19<br />
| '''2023-06-26'''<br />
| 2023-06-29<br />
| 116<br />
| 2023-07-04<br />
|-<br />
| Skipped<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<tr><br />
<td>3.94</td> <td><b>{{bug|1842932}}</b>: {{bug|1842935}}, {{bug|1850598}}, {{bug|1850982}}, {{bug|1851044}}, {{bug|1851049}}, {{bug|1855318}}, {{bug|1860670}} </td> <td>121</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
, , , , , , <br />
<tr><br />
<td>3.92</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1249052CA/Vulnerability Disclosure2023-11-22T19:27:50Z<p>Bwilson: /* Response and Mitigation */ Minor edit</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents in Bugzilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report] for non-compliances, as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
Ensure that you report security incidents to other root stores as well. Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla. (People cc:'ed in the bug have access to view the bug, so review the cc: list to ensure that no unintended people are in that list.)<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Serious vulnerabilities''' include critical software and web application vulnerabilities, faulty APIs that could lead to data breaches, zero-day exploits, and malware infections.<br />
<br />
'''Security Incidents''' include the following:<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Ransomware attacks, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability/Incident Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the nature of the compromise, the specific systems, infrastructure, or processes affected, the duration of the vulnerability/incident, and the identity of any threat actors. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report].<br />
<br />
==== Severity/Impact Assessment ====<br />
See '''"Determining Significance"''' above. <br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on subscribers, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services.<br />
# Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
# Detail any other mitigation steps or "action items" being taken to mitigate the effects of the vulnerabilities/incident, including the type of action (e.g. patching, access control, training, etc.), the status of each action, and the date each action will be completed.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
# Outline the remediation plan and summarize the actions to be taken to address the incident, root cause(s), or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation action items that you are taking to resolve the current situation, to address the root cause(s), and to ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, the type of action (e.g. governance review, enhanced alerting, training, documentation, etc.), its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.<br />
<br />
== Markdown Template ==<br />
<pre><br />
## Vulnerability/Incident Disclosure Form<br />
<br />
### Concise Summary<br />
<br />
### Vulnerability/Incident Details<br />
#### Timeline<br />
All times are UTC.<br />
<br />
YYYY-MM-DD:<br />
- HH:MM Example<br />
- <br />
#### Type and Detailed Description<br />
Nature of the compromise:<br />
Specific systems, infrastructure, or processes affected:<br />
Duration:<br />
Identity of threat actors:<br />
<br />
<br />
#### Root Cause(s)<br />
<br />
### Severity/Impact Assessment<br />
#### Potential Impact on CA operations, systems, certificate trustworthiness<br />
<br />
#### Number and type(s) of certificates affected (if any)<br />
<br />
#### Potential impact on subscribers, relying parties, and others<br />
<br />
#### Escalation Potential<br />
<br />
### Response and Mitigation<br />
#### Recommended Actions for Root Store(s)<br />
<br />
#### Immediate Actions Taken to Contain/Mitigate<br />
<br />
#### Collaboration with Forensics, CSIRTS, LEAs, etc.<br />
<br />
#### Mitigation Steps Being Taken<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- |-------- |<br />
| Example | Patching | 2024-01-19 | 50% complete |<br />
<br />
<br />
### Remediation Plan<br />
<br />
#### Outline/Summary of Remediation Plan<br />
<br />
#### Remediation Action Items<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- | -------- |<br />
| Example | Governance Review | 2024-01-19 | 50% complete |<br />
<br />
#### Additional Measures<br />
<br />
### Contact Information<br />
</pre></div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1249051CA/Vulnerability Disclosure2023-11-22T19:26:13Z<p>Bwilson: /* Response and Mitigation */ Minor edit</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents in Bugzilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report] for non-compliances, as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
Ensure that you report security incidents to other root stores as well. Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla. (People cc:'ed in the bug have access to view the bug, so review the cc: list to ensure that no unintended people are in that list.)<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Serious vulnerabilities''' include critical software and web application vulnerabilities, faulty APIs that could lead to data breaches, zero-day exploits, and malware infections.<br />
<br />
'''Security Incidents''' include the following:<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Ransomware attacks, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability/Incident Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the nature of the compromise, the specific systems, infrastructure, or processes affected, the duration of the vulnerability/incident, and the identity of any threat actors. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report].<br />
<br />
==== Severity/Impact Assessment ====<br />
See '''"Determining Significance"''' above. <br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on subscribers, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services.<br />
# Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
# Detail any mitigation steps and other action items being taken to mitigate the effects of the vulnerabilities/incident, including the type of action (e.g. patching, access control, training, etc.), the status of each action, and the date each action will be completed.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
# Outline the remediation plan and summarize the actions to be taken to address the incident, root cause(s), or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation action items that you are taking to resolve the current situation, to address the root cause(s), and to ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, the type of action (e.g. governance review, enhanced alerting, training, documentation, etc.), its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.<br />
<br />
== Markdown Template ==<br />
<pre><br />
## Vulnerability/Incident Disclosure Form<br />
<br />
### Concise Summary<br />
<br />
### Vulnerability/Incident Details<br />
#### Timeline<br />
All times are UTC.<br />
<br />
YYYY-MM-DD:<br />
- HH:MM Example<br />
- <br />
#### Type and Detailed Description<br />
Nature of the compromise:<br />
Specific systems, infrastructure, or processes affected:<br />
Duration:<br />
Identity of threat actors:<br />
<br />
<br />
#### Root Cause(s)<br />
<br />
### Severity/Impact Assessment<br />
#### Potential Impact on CA operations, systems, certificate trustworthiness<br />
<br />
#### Number and type(s) of certificates affected (if any)<br />
<br />
#### Potential impact on subscribers, relying parties, and others<br />
<br />
#### Escalation Potential<br />
<br />
### Response and Mitigation<br />
#### Recommended Actions for Root Store(s)<br />
<br />
#### Immediate Actions Taken to Contain/Mitigate<br />
<br />
#### Collaboration with Forensics, CSIRTS, LEAs, etc.<br />
<br />
#### Mitigation Steps Being Taken<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- |-------- |<br />
| Example | Patching | 2024-01-19 | 50% complete |<br />
<br />
<br />
### Remediation Plan<br />
<br />
#### Outline/Summary of Remediation Plan<br />
<br />
#### Remediation Action Items<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- | -------- |<br />
| Example | Governance Review | 2024-01-19 | 50% complete |<br />
<br />
#### Additional Measures<br />
<br />
### Contact Information<br />
</pre></div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1249050CA/Vulnerability Disclosure2023-11-22T19:21:31Z<p>Bwilson: /* Types of Vulnerabilities/Incidents to be disclosed */ Added explanation about serious vulnerabilities</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents in Bugzilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report] for non-compliances, as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
Ensure that you report security incidents to other root stores as well. Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla. (People cc:'ed in the bug have access to view the bug, so review the cc: list to ensure that no unintended people are in that list.)<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Serious vulnerabilities''' include critical software and web application vulnerabilities, faulty APIs that could lead to data breaches, zero-day exploits, and malware infections.<br />
<br />
'''Security Incidents''' include the following:<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Ransomware attacks, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability/Incident Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the nature of the compromise, the specific systems, infrastructure, or processes affected, the duration of the vulnerability/incident, and the identity of any threat actors. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report].<br />
<br />
==== Severity/Impact Assessment ====<br />
See '''"Determining Significance"''' above. <br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on subscribers, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services.<br />
# Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
# Detail any other action items being taken to mitigate the effects of the vulnerabilities/incident, including the type of action (e.g. patching, access control, training, etc.), the status of each action, and the date each action will be completed.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
# Outline the remediation plan and summarize the actions to be taken to address the incident, root cause(s), or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation action items that you are taking to resolve the current situation, to address the root cause(s), and to ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, the type of action (e.g. governance review, enhanced alerting, training, documentation, etc.), its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.<br />
<br />
== Markdown Template ==<br />
<pre><br />
## Vulnerability/Incident Disclosure Form<br />
<br />
### Concise Summary<br />
<br />
### Vulnerability/Incident Details<br />
#### Timeline<br />
All times are UTC.<br />
<br />
YYYY-MM-DD:<br />
- HH:MM Example<br />
- <br />
#### Type and Detailed Description<br />
Nature of the compromise:<br />
Specific systems, infrastructure, or processes affected:<br />
Duration:<br />
Identity of threat actors:<br />
<br />
<br />
#### Root Cause(s)<br />
<br />
### Severity/Impact Assessment<br />
#### Potential Impact on CA operations, systems, certificate trustworthiness<br />
<br />
#### Number and type(s) of certificates affected (if any)<br />
<br />
#### Potential impact on subscribers, relying parties, and others<br />
<br />
#### Escalation Potential<br />
<br />
### Response and Mitigation<br />
#### Recommended Actions for Root Store(s)<br />
<br />
#### Immediate Actions Taken to Contain/Mitigate<br />
<br />
#### Collaboration with Forensics, CSIRTS, LEAs, etc.<br />
<br />
#### Mitigation Steps Being Taken<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- |-------- |<br />
| Example | Patching | 2024-01-19 | 50% complete |<br />
<br />
<br />
### Remediation Plan<br />
<br />
#### Outline/Summary of Remediation Plan<br />
<br />
#### Remediation Action Items<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- | -------- |<br />
| Example | Governance Review | 2024-01-19 | 50% complete |<br />
<br />
#### Additional Measures<br />
<br />
### Contact Information<br />
</pre></div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1249047CA/Vulnerability Disclosure2023-11-22T19:10:47Z<p>Bwilson: /* Markdown Template */ Minor edits</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents in Bugzilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report] for non-compliances, as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
Ensure that you report security incidents to other root stores as well. Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla. (People cc:'ed in the bug have access to view the bug, so review the cc: list to ensure that no unintended people are in that list.)<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Security Incidents include the following:'''<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Malware infections, ransomware, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability/Incident Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the nature of the compromise, the specific systems, infrastructure, or processes affected, the duration of the vulnerability/incident, and the identity of any threat actors. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report].<br />
<br />
==== Severity/Impact Assessment ====<br />
See '''"Determining Significance"''' above. <br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on subscribers, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services.<br />
# Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
# Detail any other action items being taken to mitigate the effects of the vulnerabilities/incident, including the type of action (e.g. patching, access control, training, etc.), the status of each action, and the date each action will be completed.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
# Outline the remediation plan and summarize the actions to be taken to address the incident, root cause(s), or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation action items that you are taking to resolve the current situation, to address the root cause(s), and to ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, the type of action (e.g. governance review, enhanced alerting, training, documentation, etc.), its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.<br />
<br />
== Markdown Template ==<br />
<pre><br />
## Vulnerability/Incident Disclosure Form<br />
<br />
### Concise Summary<br />
<br />
### Vulnerability/Incident Details<br />
#### Timeline<br />
All times are UTC.<br />
<br />
YYYY-MM-DD:<br />
- HH:MM Example<br />
- <br />
#### Type and Detailed Description<br />
Nature of the compromise:<br />
Specific systems, infrastructure, or processes affected:<br />
Duration:<br />
Identity of threat actors:<br />
<br />
<br />
#### Root Cause(s)<br />
<br />
### Severity/Impact Assessment<br />
#### Potential Impact on CA operations, systems, certificate trustworthiness<br />
<br />
#### Number and type(s) of certificates affected (if any)<br />
<br />
#### Potential impact on subscribers, relying parties, and others<br />
<br />
#### Escalation Potential<br />
<br />
### Response and Mitigation<br />
#### Recommended Actions for Root Store(s)<br />
<br />
#### Immediate Actions Taken to Contain/Mitigate<br />
<br />
#### Collaboration with Forensics, CSIRTS, LEAs, etc.<br />
<br />
#### Mitigation Steps Being Taken<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- |-------- |<br />
| Example | Patching | 2024-01-19 | 50% complete |<br />
<br />
<br />
### Remediation Plan<br />
<br />
#### Outline/Summary of Remediation Plan<br />
<br />
#### Remediation Action Items<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- | -------- |<br />
| Example | Governance Review | 2024-01-19 | 50% complete |<br />
<br />
#### Additional Measures<br />
<br />
### Contact Information<br />
</pre></div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1249046CA/Vulnerability Disclosure2023-11-22T19:09:29Z<p>Bwilson: /* Vulnerability/Incident Details */ Minor edits</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents in Bugzilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report] for non-compliances, as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
Ensure that you report security incidents to other root stores as well. Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla. (People cc:'ed in the bug have access to view the bug, so review the cc: list to ensure that no unintended people are in that list.)<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Security Incidents include the following:'''<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Malware infections, ransomware, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability/Incident Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the nature of the compromise, the specific systems, infrastructure, or processes affected, the duration of the vulnerability/incident, and the identity of any threat actors. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report].<br />
<br />
==== Severity/Impact Assessment ====<br />
See '''"Determining Significance"''' above. <br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on subscribers, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services.<br />
# Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
# Detail any other action items being taken to mitigate the effects of the vulnerabilities/incident, including the type of action (e.g. patching, access control, training, etc.), the status of each action, and the date each action will be completed.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
# Outline the remediation plan and summarize the actions to be taken to address the incident, root cause(s), or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation action items that you are taking to resolve the current situation, to address the root cause(s), and to ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, the type of action (e.g. governance review, enhanced alerting, training, documentation, etc.), its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.<br />
<br />
== Markdown Template ==<br />
<pre><br />
## Vulnerability/Incident Disclosure Form<br />
<br />
### Concise Summary<br />
<br />
### Vulnerability/Incident Details<br />
#### Timeline<br />
All times are UTC.<br />
<br />
YYYY-MM-DD:<br />
- HH:MM Example<br />
- <br />
#### Type and Detailed Description<br />
Nature of the compromise:<br />
Specific systems, infrastructure, or processes affected:<br />
Duration:<br />
Identity of threat actors:<br />
<br />
<br />
#### Root Cause(s)<br />
<br />
### Severity/Impact Assessment<br />
#### Potential Impact on CA operations, systems, certificate trustworthiness<br />
<br />
#### Number and type(s) of certificates affected (if any)<br />
<br />
#### Potential impact on subscribers, relying parties, and others<br />
<br />
#### Escalation Potential<br />
<br />
### Response and Mitigation<br />
#### Recommended Actions for Root Store(s)<br />
<br />
#### Immediate Actions Taken to Contain/Mitigate<br />
<br />
#### Collaboration with Forensics, CSIRTS, LEAs, etc.<br />
<br />
#### Mitigation Steps Being Taken<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- |-------- |<br />
| Example | Patching | 2024-01-19 | 50% complete |<br />
<br />
<br />
### Longer-Term Remediation Measures<br />
<br />
#### Outline/Summary of Remediation Plan<br />
<br />
#### Remediation Action Items<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- | -------- |<br />
| Example | Governance Review | 2024-01-19 | 50% complete |<br />
<br />
#### Additional Measures<br />
<br />
### Contact Information<br />
</pre></div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1249045CA/Vulnerability Disclosure2023-11-22T19:05:21Z<p>Bwilson: /* Markdown Template */ Minor edits</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents in Bugzilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report] for non-compliances, as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
Ensure that you report security incidents to other root stores as well. Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla. (People cc:'ed in the bug have access to view the bug, so review the cc: list to ensure that no unintended people are in that list.)<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Security Incidents include the following:'''<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Malware infections, ransomware, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability/Incident Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the duration of the vulnerability/incident, identity of threat actors, nature of the compromise, and the specific systems, infrastructure, or processes affected. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]. <br />
<br />
==== Severity/Impact Assessment ====<br />
See '''"Determining Significance"''' above. <br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on subscribers, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services.<br />
# Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
# Detail any other action items being taken to mitigate the effects of the vulnerabilities/incident, including the type of action (e.g. patching, access control, training, etc.), the status of each action, and the date each action will be completed.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
# Outline the remediation plan and summarize the actions to be taken to address the incident, root cause(s), or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation action items that you are taking to resolve the current situation, to address the root cause(s), and to ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, the type of action (e.g. governance review, enhanced alerting, training, documentation, etc.), its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.<br />
<br />
== Markdown Template ==<br />
<pre><br />
## Vulnerability/Incident Disclosure Form<br />
<br />
### Concise Summary<br />
<br />
### Vulnerability/Incident Details<br />
#### Timeline<br />
All times are UTC.<br />
<br />
YYYY-MM-DD:<br />
- HH:MM Example<br />
- <br />
#### Type and Detailed Description<br />
Nature of the compromise:<br />
Specific systems, infrastructure, or processes affected:<br />
Duration:<br />
Identity of threat actors:<br />
<br />
<br />
#### Root Cause(s)<br />
<br />
### Severity/Impact Assessment<br />
#### Potential Impact on CA operations, systems, certificate trustworthiness<br />
<br />
#### Number and type(s) of certificates affected (if any)<br />
<br />
#### Potential impact on subscribers, relying parties, and others<br />
<br />
#### Escalation Potential<br />
<br />
### Response and Mitigation<br />
#### Recommended Actions for Root Store(s)<br />
<br />
#### Immediate Actions Taken to Contain/Mitigate<br />
<br />
#### Collaboration with Forensics, CSIRTS, LEAs, etc.<br />
<br />
#### Mitigation Steps Being Taken<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- |-------- |<br />
| Example | Patching | 2024-01-19 | 50% complete |<br />
<br />
<br />
### Longer-Term Remediation Measures<br />
<br />
#### Outline/Summary of Remediation Plan<br />
<br />
#### Remediation Action Items<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- | -------- |<br />
| Example | Governance Review | 2024-01-19 | 50% complete |<br />
<br />
#### Additional Measures<br />
<br />
### Contact Information<br />
</pre></div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1249044CA/Vulnerability Disclosure2023-11-22T19:02:22Z<p>Bwilson: Multiple edits</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents in Bugzilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report] for non-compliances, as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
Ensure that you report security incidents to other root stores as well. Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla. (People cc:'ed in the bug have access to view the bug, so review the cc: list to ensure that no unintended people are in that list.)<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Security Incidents include the following:'''<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Malware infections, ransomware, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability/Incident Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the duration of the vulnerability/incident, identity of threat actors, nature of the compromise, and the specific systems, infrastructure, or processes affected. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]. <br />
<br />
==== Severity/Impact Assessment ====<br />
See '''"Determining Significance"''' above. <br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on subscribers, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services.<br />
# Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
# Detail any other action items being taken to mitigate the effects of the vulnerabilities/incident, including the type of action (e.g. patching, access control, training, etc.), the status of each action, and the date each action will be completed.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
# Outline the remediation plan and summarize the actions to be taken to address the incident, root cause(s), or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation action items that you are taking to resolve the current situation, to address the root cause(s), and to ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, the type of action (e.g. governance review, enhanced alerting, training, documentation, etc.), its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.<br />
<br />
== Markdown Template ==<br />
<pre><br />
## Vulnerabilty/Incident Disclosure Form<br />
<br />
### Concise Summary<br />
<br />
### Vulnerability/Incident Details<br />
#### Timeline<br />
All times are UTC.<br />
<br />
YYYY-MM-DD:<br />
- HH:MM Example<br />
- <br />
#### Type and Detailed Description<br />
Duration<br />
Identity of threat actors<br />
Nature of the compromise<br />
Specific systems, infrastructure, or processes affected<br />
<br />
#### Root Cause(s)<br />
<br />
### Severity/Impact Assessment<br />
#### Potential Impact on CA operations, systems, certificate trustworthiness<br />
<br />
#### Number and type(s) of certificates affected (if any)<br />
<br />
#### Potential impact on subscribers, relying parties, and others<br />
<br />
#### Escalation Potential<br />
<br />
### Response and Mitigation<br />
#### Recommended Actions for Root Store(s)<br />
<br />
#### Immediate Actions Taken to Contain/Mitigate<br />
<br />
#### Collaboration with Forensics, CSIRTS, LEAs, etc.<br />
<br />
#### Mitigation Steps Being Taken<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- |-------- |<br />
| Example | Patching | 2024-01-19 | 50% complete |<br />
<br />
<br />
### Longer-Term Remediation Measures<br />
<br />
#### Outline/Summary of Remediation Plan<br />
<br />
#### Remediation Action Items<br />
<br />
| Action Item | Kind | Due Date | Status |<br />
| ----------- | ---- | -------- | -------- |<br />
| Example | Governance Review | 2024-01-19 | 50% complete |<br />
<br />
#### Additional Measures<br />
<br />
### Contact Information<br />
</pre></div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1249037CA/Vulnerability Disclosure2023-11-22T17:27:31Z<p>Bwilson: /* Reportable Vulnerability Disclosure Contents */ Changed subsection title</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents to Mozilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report], as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
Ensure that you report security incidents to other root stores as well. Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla. (People cc:'ed in the bug have access to view the bug, so review the cc: list to ensure that no unintended people are in that list.)<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Security Incidents include the following:'''<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Malware infections, ransomware, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability/Incident Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the duration of the vulnerability/incident, identity of threat actors, nature of the compromise, and the specific systems, infrastructure, or processes affected. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]. <br />
<br />
==== Severity / Impact Assessment ====<br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on certificate holders, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services;<br />
<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
3. Summarize the steps taken to address the root cause(s) and to strengthen security controls to prevent a similar vulnerability/incident in the future;<br />
<br />
4. Detail any other steps being taken to mitigate the effects of the vulnerabilities/incident, including the status of each action, and the date each action will be completed; and<br />
<br />
5. Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
# Outline the remediation plan and actions taken to address the incident or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation steps you are taking to resolve the situation and ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1249027NSS:Release Versions2023-11-21T21:34:04Z<p>Bwilson: /* Root Cert Inclusions into Mozilla Product Releases */ Added meta bug</p>
<hr />
<div>* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
! Release Manager<br />
|-<br />
| 3.96<br />
|<br />
|<br />
| 2023-12-07<br />
| '''2023-12-14'''<br />
| 2023-12-18<br />
| 122<br />
| TBD<br />
| A. Weine<br />
|-<br />
| 3.97<br />
|<br />
|<br />
| TBD<br />
| '''TBD'''<br />
| TBD<br />
| 123<br />
| TBD<br />
| J. Schanck<br />
|}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| NSPR version<br />
| NSS API freeze date<br />
| <b>NSS Release Date</b><br />
| FF Beta merge date<br />
| Firefox version<br />
| Firefox release date<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.95<br />
|<br />
|2.64<br />
| 2023-11-09<br />
| '''2023-11-16'''<br />
| 2023-11-20<br />
| 121<br />
| 2023-12-19<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-09-14<br />
| '''2023-09-21'''<br />
| 2023-09-25<br />
| 119<br />
| 2023-10-24<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-08-18<br />
| '''2023-08-23'''<br />
| 2023-08-25<br />
| 118<br />
| 2023-09-26<br />
|-<br />
| 3.92<br />
|<br />
| 2.62<br />
| 2023-07-12<br />
| '''2023-07-19'''<br />
| 2023-07-27<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.91 <br />(ESR)<br />
|<br />
|<br />
| 2023-06-19<br />
| '''2023-06-26'''<br />
| 2023-06-29<br />
| 116<br />
| 2023-07-04<br />
|-<br />
| Skipped<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<tr><br />
<td>3.94</td> <td><b>{{bug|1842932}}</b>: {{bug|1842935}}, {{bug|1850598}}, {{bug|1850982}}, {{bug|1851044}}, {{bug|1851049}}, {{bug|1855318}}, {{bug|1860670}} </td> <td>121</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
, , , , , , <br />
<tr><br />
<td>3.92</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1249026NSS:Release Versions2023-11-21T21:27:11Z<p>Bwilson: /* Root Cert Inclusions into Mozilla Product Releases */ Updated table FF121</p>
<hr />
<div>* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
! Release Manager<br />
|-<br />
| 3.96<br />
|<br />
|<br />
| 2023-12-07<br />
| '''2023-12-14'''<br />
| 2023-12-18<br />
| 122<br />
| TBD<br />
| A. Weine<br />
|-<br />
| 3.97<br />
|<br />
|<br />
| TBD<br />
| '''TBD'''<br />
| TBD<br />
| 123<br />
| TBD<br />
| J. Schanck<br />
|}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| NSPR version<br />
| NSS API freeze date<br />
| <b>NSS Release Date</b><br />
| FF Beta merge date<br />
| Firefox version<br />
| Firefox release date<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.95<br />
|<br />
|2.64<br />
| 2023-11-09<br />
| '''2023-11-16'''<br />
| 2023-11-20<br />
| 121<br />
| 2023-12-19<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-09-14<br />
| '''2023-09-21'''<br />
| 2023-09-25<br />
| 119<br />
| 2023-10-24<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-08-18<br />
| '''2023-08-23'''<br />
| 2023-08-25<br />
| 118<br />
| 2023-09-26<br />
|-<br />
| 3.92<br />
|<br />
| 2.62<br />
| 2023-07-12<br />
| '''2023-07-19'''<br />
| 2023-07-27<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.91 <br />(ESR)<br />
|<br />
|<br />
| 2023-06-19<br />
| '''2023-06-26'''<br />
| 2023-06-29<br />
| 116<br />
| 2023-07-04<br />
|-<br />
| Skipped<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<tr><br />
<td>3.94</td> <td><b>{{bug|1842935}}</b>: {{bug|1850598}}, {{bug|1850982}}, {{bug|1851044}}, {{bug|1851049}}, {{bug|1855318}}, {{bug|1860670}} </td> <td>121</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
, , , , , , <br />
<tr><br />
<td>3.92</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1249025NSS:Release Versions2023-11-21T21:22:11Z<p>Bwilson: Updated Future and Past Release Tables</p>
<hr />
<div>* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
! Release Manager<br />
|-<br />
| 3.96<br />
|<br />
|<br />
| 2023-12-07<br />
| '''2023-12-14'''<br />
| 2023-12-18<br />
| 122<br />
| TBD<br />
| A. Weine<br />
|-<br />
| 3.97<br />
|<br />
|<br />
| TBD<br />
| '''TBD'''<br />
| TBD<br />
| 123<br />
| TBD<br />
| J. Schanck<br />
|}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| NSPR version<br />
| NSS API freeze date<br />
| <b>NSS Release Date</b><br />
| FF Beta merge date<br />
| Firefox version<br />
| Firefox release date<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.95<br />
|<br />
|2.64<br />
| 2023-11-09<br />
| '''2023-11-16'''<br />
| 2023-11-20<br />
| 121<br />
| 2023-12-19<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-09-14<br />
| '''2023-09-21'''<br />
| 2023-09-25<br />
| 119<br />
| 2023-10-24<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-08-18<br />
| '''2023-08-23'''<br />
| 2023-08-25<br />
| 118<br />
| 2023-09-26<br />
|-<br />
| 3.92<br />
|<br />
| 2.62<br />
| 2023-07-12<br />
| '''2023-07-19'''<br />
| 2023-07-27<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.91 <br />(ESR)<br />
|<br />
|<br />
| 2023-06-19<br />
| '''2023-06-26'''<br />
| 2023-06-29<br />
| 116<br />
| 2023-07-04<br />
|-<br />
| Skipped<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<br />
<tr><br />
<td>3.92</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1248974NSS:Release Versions2023-11-14T21:02:30Z<p>Bwilson: /* Future Releases */ Edit table</p>
<hr />
<div>* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
! Release Manager<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-09-14<br />
| '''2023-09-21'''<br />
| 2023-09-25<br />
| 119<br />
| 2023-10-24<br />
| B. Beurdouche<br />
|-<br />
| 3.95<br />
|<br />
|2.64<br />
| 2023-11-09<br />
| '''2023-11-16'''<br />
| 2023-11-20<br />
| 121<br />
| 2023-12-19<br />
| D. Jackson<br />
|-<br />
| 3.96<br />
|<br />
|<br />
| 2023-12-07<br />
| '''2023-12-14'''<br />
| 2023-12-18<br />
| 122<br />
| TBD<br />
| A. Weine<br />
|-<br />
| 3.97<br />
|<br />
|<br />
| TBD<br />
| '''TBD'''<br />
| TBD<br />
| 123<br />
| TBD<br />
| J. Schanck<br />
|}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| NSPR version<br />
| NSS API freeze date<br />
| <b>NSS Release Date</b><br />
| FF Beta merge date<br />
| Firefox version<br />
| Firefox release date<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-08-18<br />
| '''2023-08-23'''<br />
| 2023-08-25<br />
| 118<br />
| 2023-09-26<br />
|-<br />
| 3.92<br />
|<br />
| 2.62<br />
| 2023-07-12<br />
| '''2023-07-19'''<br />
| 2023-07-27<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.91 <br />(ESR)<br />
|<br />
|<br />
| 2023-06-19<br />
| '''2023-06-26'''<br />
| 2023-06-29<br />
| 116<br />
| 2023-07-04<br />
|-<br />
| Skipped<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<br />
<tr><br />
<td>3.92</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=NSS:Release_Versions&diff=1248973NSS:Release Versions2023-11-14T20:58:08Z<p>Bwilson: /* Future Releases */ Updated NSS builtin library version number</p>
<hr />
<div>* '''Mozilla / NSPR / NSS versions:''' https://wiki.mozilla.org/NSS:Versions<br />
** https://kuix.de/mozilla/versions/<br />
* '''Download a Specific Firefox Release:''' ftp://ftp.mozilla.org/pub/firefox/releases/<br />
* '''NSS Release List:''' https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases<br />
* '''NSS Release Packages:''' https://ftp.mozilla.org/pub/security/nss/releases/<br />
* '''Release schedules:''' https://wiki.mozilla.org/Releases<br />
* '''Release Calendar:''' https://wiki.mozilla.org/RapidRelease/Calendar<br />
* '''Release branches:''' http://hg.mozilla.org/releases/<br />
** You can look at the release source code to see which version of NSS is included in a version of Firefox. For example, at http://hg.mozilla.org/releases/mozilla-release (choose the right tag from the bottom, e.g. FIREFOX_5_0_RELEASE, then click on files and navigate to security/nss, click on the file link next to TAG-INFO there.<br />
* '''History/Dates of NSS Branches:''' https://wiki.mozilla.org/NSS:Tags<br />
* [[CA/Included_Certificates|Spreadsheet of all included root certificates]]<br />
<br />
<!-- https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificates&target_milestone=nn.nn.nn --><br />
<br />
==Future Releases==<br />
* '''NSS Release Calendar (iCal format)''' https://calendar.google.com/calendar/ical/mozilla.com_2gnk73saaledse6q8n93b1m2u4%40group.calendar.google.com/public/basic.ics<br />
<br />
This section documents the expected future NSS/NSPR releases and their timing, aligned to the [https://wiki.mozilla.org/RapidRelease/Calendar Firefox release Calendar]:<br />
<br />
<!-- Edit with https://www.tablesgenerator.com/mediawiki_tables --><br />
{| class="wikitable" style="text-align:center;"<br />
|- style="text-align:left;"<br />
! NSS version<br />
! new<br /> NSPR version<br /> (optional)<br />
! new CA<br /> list version<br /> (optional)<br />
! NSS/NSPR API<br /> freeze & branching<br />Beta<br />
! NSS/NSPR Release<br />from branch<br />
! keep mozilla-central<br />on this NSS/NSPR branch<br />until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
! Release Manager<br />
|-<br />
| 3.94<br />
|<br />
|<br />
| 2023-09-14<br />
| '''2023-09-21'''<br />
| 2023-09-25<br />
| 119<br />
| 2023-10-24<br />
| B. Beurdouche<br />
|-<br />
| 3.95<br />
|<br />
|2.64<br />
| 2023-10-12<br />
| '''2023-10-19'''<br />
| 2023-10-23<br />
| 121<br />
| 2023-12-19<br />
| D. Jackson<br />
|-<br />
| 3.96<br />
|<br />
|<br />
| 2023-11-09<br />
| '''2023-11-16'''<br />
| 2023-11-20<br />
| 121<br />
| 2023-12-19<br />
| A. Weine<br />
|-<br />
| 3.97<br />
|<br />
|<br />
| 2023-12-07<br />
| '''2023-12-14'''<br />
| 2023-12-18<br />
| 122<br />
| TBD<br />
| J. Schanck<br />
|}<br />
<br />
<!--<br />
|-<br />
| <b>NSS version</b><br />
| NSPR version<br />
| NSS API freeze date<br />
| <b>NSS Release Date</b><br />
| FF Beta merge date<br />
| Firefox version<br />
| Firefox release date<br />
--><br />
<br />
==Past Releases==<br />
<br />
(Note the table may contain planned dates, which might differ from the actual dates.)<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! <u>NSS version</u><br />
! new<br> NSPR version<br> (optional)<br />
! new CA<br> list version<br> (optional)<br />
! NSS/NSPR API<br> freeze & branching<br><u>Beta</u><br />
! NSS/NSPR <u>Release</u><br>from branch<br />
! keep mozilla-central<br>on this NSS/NSPR branch<br>until FF Beta rollover<br />
! Firefox version<br />
! Firefox release date<br />
|-<br />
| 3.93<br />
|<br />
|<br />
| 2023-08-18<br />
| '''2023-08-23'''<br />
| 2023-08-25<br />
| 118<br />
| 2023-09-26<br />
|-<br />
| 3.92<br />
|<br />
| 2.62<br />
| 2023-07-12<br />
| '''2023-07-19'''<br />
| 2023-07-27<br />
| 117<br />
| 2023-08-29<br />
|-<br />
| 3.91 <br />(ESR)<br />
|<br />
|<br />
| 2023-06-19<br />
| '''2023-06-26'''<br />
| 2023-06-29<br />
| 116<br />
| 2023-07-04<br />
|-<br />
| Skipped<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| 3.90<br />
|<br />
|<br />
| 2023-03-30<br />
| '''2023-04-06'''<br />
| 2023-04-10<br />
| 113<br />
| 2023-05-09<br />
|-<br />
| 3.89<br />
|<br />
|<br />
| 2023-03-02<br />
| '''2023-03-09'''<br />
| 2023-03-13<br />
| 112<br />
| 2023-04-11<br />
|-<br />
| 3.88.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87.1<br />
|<br />
|<br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.79.4 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2023-02-09'''<br />
| <br />
| 102.8<br />
| 2022-02-14<br />
|-<br />
| 3.88<br />
|<br />
|<br />
| 2023-02-02<br />
| '''2023-02-09'''<br />
| 2023-02-13<br />
| 111<br />
| 2023-03-14<br />
|-<br />
| 3.87<br />
|<br />
|<br />
| 2022-12-29<br />
| '''2023-01-05'''<br />
| 2023-01-16<br />
| 110<br />
| 2023-02-14<br />
|-<br />
| 3.86<br />
|<br />
| 2.60<br />
| 2022-12-01<br />
| '''2022-12-08'''<br />
| 2022-12-12<br />
| 109<br />
| 2023-01-17<br />
|-<br />
| 3.85<br />
|<br />
|<br />
| 2022-11-03<br />
| '''2022-11-10'''<br />
| 2022-11-14<br />
| 108<br />
| 2022-12-13<br />
|-<br />
| 3.84<br />
| 4.35<br />
|<br />
| 2022-10-06<br />
| '''2022-10-13'''<br />
| 2022-10-17<br />
| 107<br />
| 2022-11-15<br />
|-<br />
| 3.83<br />
| 4.34.1<br />
| 2.58<br />
| 2022-09-08<br />
| '''2022-09-15'''<br />
| 2022-09-19<br />
| 106<br />
| 2022-10-18<br />
|-<br />
| 3.82<br />
|<br />
|<br />
| 2022-08-11<br />
| '''2022-08-18'''<br />
| 2022-08-22<br />
| 105<br />
| 2022-09-20<br />
|-<br />
| 3.79.1 (ESR)<br />
| 4.34.1<br />
| <br />
| <br />
| '''2022-08-18'''<br />
| <br />
| 102.2<br />
| 2022-08-18<br />
|-<br />
| 3.81<br />
|<br />
|<br />
| 2022-07-14<br />
| '''2022-07-21'''<br />
| 2022-07-25<br />
| 104<br />
| 2022-08-23<br />
|-<br />
| 3.80<br />
| <br />
| 2.56<br />
| 2022-06-16<br />
| '''2022-06-23'''<br />
| 2022-06-28<br />
| 103<br />
| 2022-07-26<br />
|-<br />
| 3.79 (ESR)<br />
| 4.34<br />
| <br />
| 2022-05-19<br />
| '''2022-05-26'''<br />
| 2022-05-30<br />
| 102<br />
| 2022-06-28<br />
|-<br />
| 3.78<br />
| <br />
| <br />
| 2022-04-21<br />
| '''2022-04-28'''<br />
| 2022-05-02<br />
| 101<br />
| 2022-05-31<br />
|-<br />
| 3.77<br />
| <br />
| <br />
| 2022-03-24<br />
| '''2022-03-31'''<br />
| 2022-04-04<br />
| 100<br />
| 2022-05-03<br />
|-<br />
| 3.76<br />
| <br />
| <br />
| 2022-02-24<br />
| '''2022-03-03'''<br />
| 2022-03-08<br />
| 99<br />
| 2022-04-05<br />
|-<br />
| '''3.75'''<br />
| <br />
| <br />
| 2022-01-27<br />
| '''2022-02-03'''<br />
| 2022-02-07<br />
| 98<br />
| 2022-03-08<br />
|-<br />
| <b>3.74</b><br />
| <br />
| 2.54<br />
| 2021-12-30<br />
| <b>2022-01-06</b><br />
| 2022-01-10<br />
| 97<br />
| 2022-02-08<br />
|-<br />
| <b>3.73.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 96.0b6<br />
| 2022-01-11<br />
|-<br />
| <b>3.72.1</b><br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
| <br />
| 95.0.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.68.2</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-15</b><br />
|<br />
| 91.4.1<br />
| 2021-12-15<br />
|-<br />
| <b>3.73</b><br />
| <br />
| <br />
| 2021-11-25<br />
| <b>2021-12-01</b><br />
| 2021-12-06<br />
| 96<br />
| 2022-01-11<br />
|-<br />
| <b>3.68.1</b> (ESR)<br />
| <br />
| <br />
|<br />
| <b>2021-12-01</b><br />
|<br />
| 91.5.0<br />
| 2022-01-11<br />
|-<br />
| <b>3.72</b><br />
| <br />
| <br />
| 2021-10-22<br />
| <b>2021-10-28</b><br />
| 2021-11-02<br />
| 95<br />
| 2021-12-07<br />
|-<br />
| <b>3.71</b><br />
| <br />
| 2.52<br />
| 2021-09-24<br />
| <b>2021-09-30</b><br />
| 2021-10-05<br />
| 94<br />
| 2021-11-02<br />
|-<br />
| <b>3.70</b><br />
| <br />
| <br />
| 2021-08-27<br />
| <b>2021-09-02</b><br />
| 2021-09-07<br />
| 93<br />
| 2021-10-05<br />
|-<br />
| <b>3.69.1</b><br />
| <br />
| <br />
| 2021-08-26<br />
| <b>2021-08-26</b><br />
| 2021-08-26<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.69</b><br />
| <br />
| <br />
| 2021-07-30<br />
| <b>2021-08-05</b><br />
| 2021-08-10<br />
| 92<br />
| 2021-09-07<br />
|-<br />
| <b>3.68</b> (ESR)<br />
| 4.32<br />
| <br />
| 2021-07-02<br />
| <b>2021-07-08</b><br />
| 2021-07-13<br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.67</b><br />
| 4.31<br />
| <br />
| 2021-06-07<br />
| <b>2021-06-10</b><br />
| <br />
| 91<br />
| 2021-08-10<br />
|-<br />
| <b>3.66</b><br />
|<br />
| 2.50<br />
| 2021-05-27<br />
| <b>2021-05-27</b><br />
| 2021-06-02<br />
| 90<br />
| 2021-07-13<br />
|-<br />
| <b>3.65</b><br />
|<br />
| <br />
| 2021-05-10<br />
| <b>2021-05-13</b><br />
| 2021-05-17<br />
| 90<br />
| 2021-06-15<br />
|-<br />
| <b>3.64</b><br />
|<br />
| <br />
| 2021-04-12<br />
| <b>2021-04-15</b><br />
| 2021-04-19<br />
| 89<br />
| 2021-05-18<br />
|-<br />
| <b>3.63.1</b><br />
|<br />
|<br />
| 2021-04-06<br />
| <b>2021-04-06</b><br />
| 2021-04-06<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.63</b><br />
| 4.30<br />
| 2.48<br />
| 2021-03-15<br />
| <b>2021-03-18</b><br />
| 2021-03-22<br />
| 88<br />
| 2021-04-20<br />
|-<br />
| <b>3.62</b><br />
|<br />
|<br />
| 2021-02-15<br />
| <b>2021-02-19</b><br />
| 2021-02-22<br />
| 87<br />
| 2021-03-23<br />
|-<br />
| <b>3.61</b><br />
|<br />
|<br />
| 2021-01-18<br />
| <b>2021-01-22</b><br />
| 2021-01-25<br />
| 86<br />
| 2021-02-23<br />
|-<br />
| <b>3.60</b><br />
|<br />
| 2.46<br />
| 2020-12-07<br />
| <b>2020-12-11</b><br />
| 2020-12-14<br />
| 85<br />
| 2021-01-26<br />
|-<br />
| <b>3.59.1</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.59</b><br />
|<br />
|<br />
| 2020-11-09<br />
| <b>2020-11-13</b><br />
| 2020-11-16<br />
| 84<br />
| 2020-12-15<br />
|-<br />
| <b>3.58</b><br />
|<br />
|<br />
| 2020-10-12<br />
| <b>2020-10-16</b><br />
| 2020-10-19 <br />
| 83<br />
| 2020-11-17 <br />
|-<br />
| <b>3.57</b><br />
| 4.29<br />
| 2.44<br />
| 2020-09-14<br />
| <b>2020-09-18</b><br />
| 2020-09-21 <br />
| 82<br />
| 2020-10-20 <br />
|-<br />
| <b>3.56</b><br />
| 4.28<br />
|<br />
| 2020-08-17<br />
| <b>2020-08-21</b><br />
| 2020-08-24 <br />
| 81<br />
| 2020-09-22<br />
|-<br />
| <b>3.55</b><br />
| 4.27<br />
|<br />
| 2020-07-20<br />
| <b>2020-07-23</b><br />
| 2020-07-27 <br />
| 80<br />
| 2020-08-25<br />
|-<br />
| <b>3.54</b><br />
| 4.26<br />
| 2.42<br />
| 2020-06-22<br />
| <b>2020-06-26</b><br />
| 2020-06-29<br />
| 79<br />
| 2020-07-28<br />
|-<br />
| <b>3.53.1</b><br />
|<br />
|<br />
| 2020-06-16<br />
| <b>2020-06-16</b><br />
| 2020-06-16<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.53</b><br />
|<br />
|<br />
| 2020-05-25<br />
| <b>2020-05-29</b><br />
| 2020-06-01<br />
| 78<br />
| 2020-06-30<br />
|-<br />
| <b>3.52</b><br />
| <br />
| <br />
| 2020-04-27<br />
| <b>2020-04-30</b><br />
| 2020-05-06<br />
| 77<br />
| 2020-06-02<br />
|-<br />
| <b>3.51.1</b><br />
| <br />
| <br />
| 2020-03-30<br />
| <b>2020-04-03</b><br />
| 2020-04-08<br />
| 76<br />
| 2020-05-05<br />
|-<br />
| <b>3.51</b><br />
| <br />
| <br />
| 2020-03-02<br />
| <b>2020-03-06</b><br />
| 2020-03-10<br />
| 75<br />
| 2020-04-07<br />
|-<br />
| <b>3.50</b><br />
| 4.25<br />
| <br />
| 2020-02-03<br />
| <b>2020-02-07</b><br />
| 2020-02-11<br />
| 74<br />
| 2020-03-10<br />
|-<br />
| <b>3.49</b><br />
| <br />
| <br />
| 2019-12-30<br />
| <b>2020-01-03</b><br />
| 2019-01-07<br />
| 73<br />
| 2020-02-11<br />
|-<br />
| <b>3.48</b><br />
| 4.24<br />
| 2.40<br />
| 2019-11-29<br />
| <b>2019-12-02</b><br />
| 2019-12-02<br />
| 72<br />
| 2020-01-07<br />
|-<br />
| <b>3.47</b><br />
| 4.23<br />
| 2.38<br />
| 2019-10-11<br />
| <b>2019-10-18</b><br />
| 2019-10-21<br />
| 71<br />
| 2019-12-10<br />
|-<br />
| <b>3.46</b><br />
| <br />
| 2.36<br />
| 2019-08-23<br />
| <b>2019-08-30</b><br />
| 2019-09-02<br />
| 70<br />
| 2019-10-22<br />
|-<br />
| <b>3.45</b><br />
| <br />
| 2.34<br />
| 2019-06-28<br />
| <b>2019-07-05</b><br />
| 2019-07-08<br />
| 69<br />
| 2019-09-03<br />
|-<br />
| <b>3.44</b> (ESR)<br />
| <br />
|<br />
| 2019-05-03<br />
| <b>2019-05-10</b><br />
| 2019-05-13<br />
| 68<br />
| 2019-07-09<br />
|-<br />
| <b>3.43</b><br />
| 4.21<br />
| 2.32<br />
| 2019-03-08<br />
| <b>2019-03-15</b><br />
| 2019-03-18<br />
| 67<br />
| 2019-05-21<br />
|-<br />
| <b>3.42</b><br />
| <br />
| <br />
| 2019-01-21<br />
| <b>2019-01-25</b><br />
| 2019-01-28<br />
| 66<br />
| 2019-03-19<br />
|-<br />
| <b>3.41</b><br />
| <br />
| 2.30<br />
| 2018-12-03<br />
| <b>2018-12-03</b><br />
| 2018-12-07<br />
| 65<br />
| 2019-01-29<br />
|-<br />
| <b>3.40</b><br />
| <br />
| 2.28<br />
| 2018-10-11<br />
| <b>2018-10-18</b><br />
| 2018-10-22<br />
| 64<br />
| 2018-12-11<br />
|-<br />
| <b>3.39</b><br />
| 4.20<br />
| 2.26<br />
| 2018-08-16<br />
| <b>2018-08-23</b><br />
| 2018-08-27<br />
| 63<br />
| 2018-10-23<br />
|-<br />
| <b>3.38</b><br />
| <br />
|<br />
| 2018-06-14<br />
| <b>2018-06-21</b><br />
| 2018-06-25<br />
| 62<br />
| 2018-08-28<br />
|-<br />
| <b>3.37</b><br />
| <br />
| 2.24<br />
| 2018-04-26<br />
| <b>2018-05-03</b><br />
| 2018-05-07<br />
| 61<br />
| 2018-06-28<br />
|-<br />
| <b>3.36</b> (ESR)<br />
| 4.19<br />
|<br />
| 2018-02-22<br />
| <b>2018-03-01</b><br />
| 2018-03-05<br />
| 60<br />
| 2018-05-01<br />
|-<br />
| <b>3.35</b><br />
| 4.18<br />
| 2.22<br />
| 2018-01-04<br />
| <b>2018-01-11</b><br />
| 2018-01-15<br />
| 59<br />
| 2018-03-06<br />
|-<br />
| <b>3.34.1</b><br />
| <br />
| 2.20<br />
|<br />
| 2017-11-24<br />
|<br />
| 58<br />
|<br />
|-<br />
| <b>3.34</b><br />
| <br />
| 2.18<br />
| 2017-10-30<br />
(3 days early)<br />
| <b>2017-11-08<br />
(1 day early)</b><br />
| 2017-11-13<br />
| 58<br />
| 2018-01-16<br />
|-<br />
| <b>3.33</b><br />
| 4.17<br />
| <br />
| 2017-09-14<br />
| <b>2017-09-21</b><br />
| 2017-09-25<br />
| 57<br />
| 2017-11-14<br />
|-<br />
| <b>3.32</b><br />
| 4.16<br />
| 2.16<br />
| 2017-07-27<br />
| <b>2017-08-03</b><br />
| 2017-08-07<br />
| 56<br />
| 2017-09-26<br />
|}<br />
<br />
==Root Cert Inclusions into Mozilla Product Releases==<br />
In the following table, only those bugs involving root certificates are listed. A <b>bold</b> bug number is a Meta bug for the NSS version with following non-bold bug numbers pointing to bug reports for individual root certificates or groups of certificates and depending on that Meta bug. For a given NSS version, bug numbers after a blank line are not related to the group above that line. <br />
<br />
[[Thunderbird/New_Release_and_Governance_Model#Releases|Thunderbird]] is built from two repos, the same "mozilla-central" that [[RapidRelease/Calendar#Future_branch_dates|Firefox ESR]] is built from, and "comm-central" for the Thunderbird-specific code. So, Thunderbird will have the same root store as ESR. ESR only picks up a new version of NSS (with the updates to the root store) when a new version (xx.0) is created. So, Thunderbird 45.0 and all of its dot releases will have the same root store as Firefox 45 / ESR 45 (NSS 3.21), unless there is a security incident.<br />
<br />
[https://en.wikipedia.org/wiki/SeaMonkey#Release_history SeaMonkey] is also built out of comm-central and pulls mozilla-central as a starting point. Very much like Thunderbird except SeaMonkey uses the mozilla-release branch rather than the ESR branch. The SeaMonkey release should have the same NSS code and root certs as the corresponding [[RapidRelease/Calendar#Future_branch_dates|Firefox release]]. SeaMonkey often ships a week after Firefox.<br />
<br />
<table border="1"><br />
<br />
<tr><br />
<th rowspan=2>NSS Version</th> <th rowspan=2>NSS Certificate Bugs</th><th colspan=3>Product Releases</th></tr><br />
<tr><br />
<th>&nbsp;&nbsp;Firefox&nbsp;&nbsp;</th> <th>Thunderbird </th> <th>SeaMonkey</th> <br />
</tr><br />
<br />
<tr><br />
<td>3.92</td> <td><b>{{bug|1822935}}</b>: {{bug|1833270}}, {{bug|1839992}}, {{bug|1840429}}, {{bug|1840437}}, {{bug|1822936}}, {{bug|1827224}}, {{bug|1840505}}, {{bug|1842928}} </td> <td>117</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.89.1</td> <td><b>{{bug|1804498}}</b>: {{bug|1804505}}, {{bug|1822921}}, {{bug|1822925}} </td> <td>114</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.86</td> <td><b>{{bug|1794506}}</b>: {{bug|1794495}}, {{bug|1794507}}, {{bug|1797559}}, {{bug|1799038}}, {{bug|1803453}} </td> <td>109</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.83</td> <td><b>{{bug|1778413}}</b>: {{bug|1785297}}, {{bug|1787075}}, {{bug|1778412}}</td> <td>106</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.80</td> <td><b>{{bug|1764206}}</b>: {{bug|1759815}}, {{bug|1764392}}, {{bug|1768970}}, {{bug|1770267}}</td> <td>103</td> <td>TBD</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.74</td> <td><b>{{bug|1733003}}</b>: {{bug|1733012}}, {{bug|1733560}}, {{bug|1735407}}, {{bug|1738805}}, {{bug|1740095}}, {{bug|1740807}}, {{bug|1741930}}</td> <td>97</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.71</td> <td><b>{{bug|1717716}}</b>: {{bug|1717707}}, {{bug|1728394}}</td> <td>94</td> <td>102</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.66</td> <td><b>{{bug|1712229}}</b>: {{bug|1697071}}, {{bug|1703942}}, {{bug|1707097}}, {{bug|1708307}}, {{bug|1710716}}</td> <td>90</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.63</td> <td><b>{{bug|1693217}}</b>: {{bug|1683738}}, {{bug|1686854}}, {{bug|1687822}}, {{bug|1692094}}, {{bug|1693173}}</td> <td>88</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<br />
<tr><br />
<td>3.60</td> <td><b>{{bug|1678189}}</b>: {{bug|1670769}}, {{bug|1678166}}</td> <td>85</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.57</td> <td>{{bug|1663049}}, {{bug|1651211}}, {{bug|1656077}}, {{bug|1653092}}</td> <td>82</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.54</td> <td>{{bug|1618402}}, {{bug|1621151}}, {{bug|1639987}}, {{bug|1641716}}, {{bug|1641718}}, {{bug|1645174}}, {{bug|1645186}}, {{bug|1645199}}</td> <td>79</td> <td>91</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.53</td> <td>{{bug|1618404}}, {{bug|1621159}}</td> <td>78</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.48</td> <td>{{bug|1591178}}</td> <td>72</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.46</td> <td>{{bug|1566569}}, {{bug|1574670}}</td> <td>70</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.45</td> <td>{{bug|1552374}}</td> <td>69</td> <td>78</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.43</td> <td><b>{{bug|1533087}}</b>: {{bug|1515457}}, {{bug|1532753}}</td> <td>67</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.41</td> <td><b>{{bug|1505899}}</b>: {{bug|1496204}}, {{bug|1496214}}, {{bug|1499320}}, {{bug|1501457}}, {{bug|1505614}} </td> <td>65</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.40</td> <td>{{bug|1493822}}</td> <td>64</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.39</td> <td><b>{{bug|1478638}}</b>: {{bug|1462098}}, {{bug|1465625}}, {{bug|1478476}}, {{bug|1483924}} </td> <td>63</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.37</td> <td><b>{{bug|1452695}}</b>: {{bug|1432959}}, {{bug|1448506}} </td> <td>61</td> <td>68</td> <td>TBD</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.35</td> <td><b>{{bug|1427977}}</b>: {{bug|1410277}}, {{bug|1410544}}, {{bug|1413330}}, {{bug|1421810}}, {{bug|1421814}} </td> <td>59</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34.1</td> <td>{{bug|1418678}} </td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.34</td> <td><b>{{bug|1408080}}</b>: {{bug|1367265}}, {{bug|1385063}}, {{bug|1387260}}, {{bug|1392849}}, {{bug|1392853}}, {{bug|1395726}}, {{bug|1400013}}, {{bug|1400021}}, {{bug|1400030}}, {{bug|1403549}}, {{bug|1410954}}</td> <td>58</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.32</td> <td><b>{{bug|1380941}}</b>: {{bug|1359515}}, {{bug|1366114}}, {{bug|1366243}}, {{bug|1366403}}, {{bug|1366412}}, {{bug|1380868}}</td> <td>56</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.5, 3.30.2</td> <td><b>{{bug|1350859}}</b>: {{bug|1268219}}, {{bug|1332059}}, {{bug|1335902}}, {{bug|1339294}}, {{bug|1342085}}, {{bug|1348132}}, {{bug|1349705}}</td> <td>54</td> <td>60</td> <td>2.53</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.28.1</td> <td><b>{{bug|1296697}}</b>: {{bug|1266574}}, {{bug|1272158}}, {{bug|1283326}}, {{bug|1299951}}, {{bug|1303377}}, {{bug|1307981}}, {{bug|1320783}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.27</td> <td><b>{{bug|1296689}}</b>: {{bug|1250699}}, {{bug|1251025}}, {{bug|1286696}}, {{bug|1288250}}</td> <td>51</td> <td>52</td> <td>2.48</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.26</td> <td><b>{{bug|1290999}}</b>: {{bug|1289889}}</td> <td>50</td> <td>52</td> <td>2.47</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.25</td> <td><b>{{bug|1275533}}</b>: {{bug|1256494}}, {{bug|1272161}}, {{bug|1274674}}</td> <td>49</td> <td>52</td> <td>2.46</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.23, 3.22.2</td> <td><b>{{bug|1247990}}</b>: {{bug|1157375}}, {{bug|1229094}}, {{bug|1229885}}, {{bug|1236962}}, {{bug|1237817}}, {{bug|1243869}}, {{bug|1247711}}</td> <td>46</td> <td>52</td> <td>2.43</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.21</td> <td><b>{{bug|1214729}}</b>: {{bug|1156844}}, {{bug|1190946}}, {{bug|1193476}}, {{bug|1204962}}, {{bug|1204997}}, {{bug|1205108}}, {{bug|1208461}}, {{bug|1213042}}, {{bug|1213086}}</td> <td>44</td> <td>45</td> <td>2.41</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.19.3</td> <td><b>{{bug|1175227}}</b>: {{bug|1147672}}, {{bug|1159294}}, {{bug|1160208}}, {{bug|1164606}}, {{bug|1165992}}, {{bug|1166025}}, {{bug|1169083}}</td> <td>42</td> <td>45</td> <td>2.39</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.18</td> <td><b>{{bug|1132496}}</b>: {{bug|1105374}}, {{bug|1108770}}, {{bug|1118020}}, {{bug|1118079}}, {{bug|1120604}}, {{bug|1131698}}</td> <td>38</td> <td>38</td> <td>2.35</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.17.3</td> <td><b>{{bug|1088147}}</b>: {{bug|986014}}, {{bug|1047011}}, {{bug|1062589}}, {{bug|1069627}}, {{bug|1083294}}</td> <td>36</td> <td>38</td> <td>2.33</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16.3, 3.16.4</td> <td><b>{{bug|1021967}}</b>: {{bug|936304}}, {{bug|986005}}, {{bug|1013572}}, {{bug|1017262}}, {{bug|1017295}}, {{bug|1020729}}, {{bug|1021039}}, {{bug|1021054}}, {{bug|1045189}}, {{bug|1046343}}</td> <td>32</td> <td>38</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.16</td> <td><b>{{bug|957300}}</b>: {{bug|847588}}, {{bug|915935}}, {{bug|919480}}, {{bug|925412}}, {{bug|935687}}, {{bug|938814}}</td> <td>29</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15.4</td> <td><b>{{bug|911960}}</b>: {{bug|860929}}, {{bug|872279}}, {{bug|896546}}, {{bug|901605}}</td> <td>27</td> <td>31</td> <td>2.30</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.15</td> <td><b>{{bug|857615}}</b>: {{bug|768547}}, {{bug|799692}}, {{bug|810010}}, {{bug|823753}}, {{bug|823766}}, {{bug|845132}}, {{bug|856678}}, {{bug|856695}}, {{bug|856718}}</td> <td>23</td> <td>24</td> <td>2.23</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.14</td> <td><b>{{bug|795355}}</b>: {{bug|760297}}, {{bug|795020}}</td> <td>18</td> <td>24</td> <td>2.16</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.6</td> <td><b>{{bug|757197}}</b>: {{bug|718841}}, {{bug|722843}}, {{bug|742514}}, {{bug|742525}}, {{bug|751954}}, {{bug|752103}}, {{bug|752110}}, {{bug|760167}}</td> <td>16</td> <td>17</td> <td>2.13</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.2</td> <td><b>{{bug|711829}}</b>: {{bug|680979}}, {{bug|707995}}, {{bug|708009}}, {{bug|708016}}, {{bug|711594}}</td> <td>11</td> <td>17</td> <td>2.8</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13.1</td> <td><b>{{bug|695833}}:</b> No root certificates implemented.</td> <td>9.0</td> <td>9.0</td> <td>2.6</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.13</td> <td>Not contained in an end-user release of any application. Replaced by NSS 3.13.1.</td> <td>n/a</td> <td>n/a</td> <td>n/a</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.11</td> <td><b>{{bug|671002}}</b>: {{bug|645880}}, {{bug|653761}}, {{bug|661672}}, {{bug|666681}}, {{bug|670790}}</td> <td>6.0.2</td> <td>6.0.2</td> <td>2.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.10</td> <td><b>{{bug|642129}}</b>: {{bug|632461}}, {{bug|633546}}, {{bug|635385}}<br><br><b>{{bug|622719}}</b>: {{bug|605187}}, {{bug|617664}} </td> <td>6.0</td> <td>6.0</td> <td>2.3, 2.3.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.9</td> <td><b>{{bug|613394}}</b>: {{bug|562395}}, {{bug|578491}}, {{bug|585518}}, {{bug|592939}}, {{bug|593063}}, {{bug|595013}}, {{bug|601718}}<br><br>{{bug|585518}}, {{bug|592939}} </td> <td>4.0</td> <td>3.1.10</td> <td>2.1</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.8</td> <td><b>{{bug|582575}}</b>: {{bug|515462}}, {{bug|557904}}, {{bug|571932}}, {{bug|582375}} </td> <td>3.6.12</td> <td>3.1.6</td> <td>2.1 Beta</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.7</td> <td>{{bug|530853}}, {{bug|554334}}</td> <td>3.6.7</td> <td>3.1.2</td> <td>2.1 Alpha</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.6</td> <td><b>{{bug|542476}}</b>: {{bug|529874}}, {{bug|532201}}, {{bug|532742}}, {{bug|539235}}, {{bug|541499}}, {{bug|542798}}<br><br>{{bug|517234}}</td> <td>3.6.2</td> <td>3.0.4</td> <td>2.0.4</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.5</td> <td>{{bug|496193}}, {{bug|499705}}, {{bug|499712}}, {{bug|509440}}, {{bug|515470}}, {{bug|515472}}, {{bug|517242}}</td> <td>3.6</td> <td>3.0.2</td> <td>2.0.3</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.4</td> <td> </td> <td>3.5</td> <td>3.0b3</td> <td>2.0</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.12.1</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.10</td> <td> </td> <td>3.0.2</td> <td>2.0.0.17</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.9</td> <td> </td> <td>2</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.11.8</td> <td> </td> <td>2.0.0.5</td> <td>2</td> <td>-</td> <br />
</tr><br />
<br />
<tr><br />
<td>3.10</td> <td> </td> <td>1</td> <td>1</td> <td>-<td> <br />
</tr><br />
<br />
</table><br />
<br />
<br />
[[Category:NSS]]</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Certificate_Change_Process&diff=1248939CA/Certificate Change Process2023-11-13T17:22:25Z<p>Bwilson: /* Remove or Disable a Root */ Updated with information about security incident reporting</p>
<hr />
<div>= Changing a Root Certificate that is Currently Included in NSS =<br />
<br />
This page describes how to change the default settings of a root certificate that is currently included in NSS. <br />
<br />
Reasons to change a root certificate in NSS may included, but are not limited to:<br />
<br />
* Security Compromise<br />
* Add a Trust Bit (one of Websites, Email)<br />
* Enable EV<br />
* Disable a Root (turn off one or more of the trust bits)<br />
* Remove a Root<br />
<br />
== Security Compromise ==<br />
<br />
When a serious security concern is noticed, such as a root compromise, it should be treated as a security-sensitive bug, and a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Security%20Vulnerability&groups=ca-program-security secure bug should be filed in Bugzilla].<br />
<br />
To report a concern about certificates being issued by a CA in Mozilla's Program:<br />
<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&version=other<br />
<br />
Open CA Mis-Issuance and other compliance bugs: https://wiki.mozilla.org/CA/Incident_Dashboard<br />
<br />
== Add a Trust Bit ==<br />
<br />
When a root certificate is included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS], one or more of the trust bits (websites, email) are enabled. It is common for a CA to request inclusion with one of the trust bits enabled, and then later request that the other trust bit be enabled. The following steps outline how a CA may request to enable an additional trust bit for a root certificate that is included in NSS.<br />
<br />
# Do some initial preparations before you formally submit a request: <br />
#* Update the CP/CPS to reflect the policies for the additional trust bits, and make sure that the additions to the CP/CPS follow [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy]. <br />
#* Review [[CA/Required_or_Recommended_Practices|Required Practices]] and [[CA/Forbidden_or_Problematic_Practices|Forbidden Practices]].<br />
#* Have the annual audit cover the updated CP/CPS.<br />
#* Make sure that the audit and audit statements meet the requirements stated in [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits Mozilla's Root Store Policy].<br />
# Once you are ready, formally [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|submit your request]]<br />
#* Click on the "Create a new bug report" link in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|Application Instructions]]. <br />
#* Set the bug summary to "Enable trust bits for <name of your root>".<br />
#* Provide all of the required information by creating a [[CA/Information_Checklist#Create_a_Root_Inclusion_Case|Root Inclusion Case in the CCADB]].<br />
# The request will go through the [[CA/Application_Verification#Information_Verification|Information Verification]], [[CA/Application_Verification#Detailed_Review|Detailed Review]], [[CA/Application_Verification#Public_Discussion|Public Discussion]], and [[CA/Application_Verification#NSS_and_PSM_Bug_Creation|Inclusion]] phases as described in [[CA/Application_Process#Process_Overview|Application Process Overview]].<br />
<br />
== Enable EV ==<br />
<br />
The following steps outline the procedure for a CA to request that Extended Validation (EV) treatment be enabled for a root certificate that is currently included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS].<br />
<br />
# Do some initial preparations before you formally submit a request: <br />
#* Update the CP/CPS to reflect the EV policies, and make sure that the additions to the CP/CPS follow [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy] as well as the [https://cabforum.org/extended-validation/ CA/Browser Forum's EV SSL Certificate Guidelines]. <br />
#* Review [[CA/Required_or_Recommended_Practices|Required Practices]] and [[CA/Forbidden_or_Problematic_Practices|Forbidden Practices]].<br />
#* Complete an EV audit that meets the requirements stated in [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits Mozilla's Root Store Policy].<br />
# Once you are ready, formally [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|submit your request]]<br />
#* Click on the "Create a new bug report" link in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|Application Instructions]]. <br />
#* Set the bug summary to "Enable EV for <name of your root>"..<br />
#* Provide all of the required information by creating a [[CA/Information_Checklist#Create_a_Root_Inclusion_Case|Root Inclusion Case in the CCADB]].<br />
#* Run the [[PSM:EV_Testing_Easy_Version#EV-Readiness_Check|EV-Readiness Check]].<br />
# The request will go through the [[CA/Application_Verification#Information_Verification|Information Verification]], [[CA/Application_Verification#Detailed_Review|Detailed Review]], [[CA/Application_Verification#Public_Discussion|Public Discussion]], and [[CA/Application_Verification#NSS_and_PSM_Bug_Creation|Inclusion]] phases as described in [[CA/Application_Process#Process_Overview|Application Process Overview]].<br />
<br />
== Remove or Disable a Root ==<br />
Disabling a Root means one or more of the following:<br />
* Turn off trust bits (Websites, Email)<br />
* Turn off EV Treatment <br />
* Distrust certificates issued after a certain date (Distrust for TLS After, Distrust for S/MIME After)<br />
<br />
Reasons for removing or disabling a root certificate may include:<br />
* [https://wiki.mozilla.org/CA/Vulnerability_Disclosure Security Compromise]<br />
* Expired or Expiring CA <br />
* Small modulus key length<br />
* Outdated signing key algorithm<br />
* Transition/Rollover to new root completed <br />
* Legacy, no longer in use <br />
* No recent audit <br />
<br />
'''Important:''' Root changes that are motivated by a serious security concern such as a root compromise should be treated as a security-sensitive bug, and a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Security%20Vulnerability&groups=ca-program-security secure bug filed in Bugzilla].<br />
<br />
Otherwise, the ordinary or usual process for removing or disabling a root in NSS is as follows:<br />
# Initiate the request:<br />
#* [https://bugzilla.mozilla.org/enter_bug.cgi?&component=CA%20Certificate%20Root%20Program&product=CA%20Program&short_desc=Remove%20%5Byour%20CA%27s%20name%5D%20root%20certificate%28s%29 File a bug in Bugzilla] with the following information:<br />
#** Product: CA Program<br />
#** Component: CA Certificate Root Program <br />
#** Summary should be one of: <br />
#*** Remove <CN or cert name> root cert<br />
#*** Turn off Trust Bit(s) for <CN or cert name> root cert <br />
#*** Turn off EV Treatment for <CN or cert name> root cert <br />
#*** Set Distrust After for <CN or cert name> root cert <br />
#** Description: Include the following information <br />
#*** Subject/Issuer field values in the root certificate to be changed<br />
#*** SHA256 Fingerprint of the certificate to be changed<br />
#*** Specify the change to be made. e.g. if the root is to be removed, or which trust bits are to be turned off, or the distrust-after dates<br />
#**** Consideration: For a serious situation, it might be better to disable the trust bits of that root, rather than just remove the root. If the root is removed, it could potentially be signed by another root that is included in NSS. However, if we disable the trust bits by default, then that root could not be used again for TLS in Firefox unless a user specifically turned on the websites trust bit for it.<br />
#*** Reason for requesting this change<br />
#*** Impact that the change may have on Mozilla users<br />
#* The bug may be marked as security-sensitive. Security-sensitive bugs can be viewed only by a select set of Bugzilla users, not by the general public.<br />
#** The security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update changing the trust bits of the root. <br />
#* In most situations, an authoritative representative of the CA must request or approve the change. Mozilla reserves the right to approve the change without the consent of the CA. <br />
# The bug will be assigned to the Mozilla representative who is appointed to evaluate the request. This will usually be the [[Modules/Activities#CA_Certificates|CA Certificates Module Owner]].<br />
# The Mozilla representative will ensure the necessary information has been provided.<br />
#* Options should be identified <br />
#** Which trust bits to unset (Websites, Email)<br />
#** Whether the root certificate should be removed from NSS instead of unsetting trust bits<br />
#* Technical assistance may be requested<br />
#* Additional information may be requested of CA and other parties<br />
#* The Mozilla representative must confirm that a qualified representative has approved the change. A qualified representative is either<br />
#** The known representative of the CA, or<br />
#** Two Mozilla staff members, if the CA is not in agreement.<br />
# The Mozilla representative will deliver any preliminary decisions<br />
#* It may be necessary to treat the bug as a sensitive security issue and follow the [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla Policy for Handling Security Bugs] or the '''[https://wiki.mozilla.org/CA/Vulnerability_Disclosure root program's security incident reporting process]'''.<br />
# Implementation<br />
#* If the resulting decision is to change the root certificate, the Mozilla representative will create a corresponding NSS bug to make the actual changes in NSS, and mark that bug as blocking the original change request.<br />
#* A Mozilla representative makes the changes in an [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] branch, and requests code review.<br />
#* A Mozilla representative commits the changes into NSS, and marks the bug RESOLVED FIXED.<br />
#* A Mozilla representative confirms the changes in Firefox Nightly, then updates the corresponding records in the [https://www.ccadb.org/ CCADB].<br />
#* For security-sensitive bugs, the security update will proceed as described in [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Policy for Handling Security Bugs]<br />
#* For non-security-sensitive requests, some time after the bug is marked as RESOLVED FIXED, various Mozilla products will move to using a version of NSS which contains the change. This process is mostly under the control of the release drivers for those products.<br />
# Notification <br />
#* The CA is responsible for providing appropriate notification to users who may be impacted by the change.<br />
#* For [http://www.mozilla.org/projects/security/security-bugs-policy.html Security-sensitive] requests the security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update removing the root.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Certificate_Change_Process&diff=1248938CA/Certificate Change Process2023-11-13T17:12:18Z<p>Bwilson: /* Remove or Disable a Root */ Updated security bug link</p>
<hr />
<div>= Changing a Root Certificate that is Currently Included in NSS =<br />
<br />
This page describes how to change the default settings of a root certificate that is currently included in NSS. <br />
<br />
Reasons to change a root certificate in NSS may included, but are not limited to:<br />
<br />
* Security Compromise<br />
* Add a Trust Bit (one of Websites, Email)<br />
* Enable EV<br />
* Disable a Root (turn off one or more of the trust bits)<br />
* Remove a Root<br />
<br />
== Security Compromise ==<br />
<br />
When a serious security concern is noticed, such as a root compromise, it should be treated as a security-sensitive bug, and a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Security%20Vulnerability&groups=ca-program-security secure bug should be filed in Bugzilla].<br />
<br />
To report a concern about certificates being issued by a CA in Mozilla's Program:<br />
<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&version=other<br />
<br />
Open CA Mis-Issuance and other compliance bugs: https://wiki.mozilla.org/CA/Incident_Dashboard<br />
<br />
== Add a Trust Bit ==<br />
<br />
When a root certificate is included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS], one or more of the trust bits (websites, email) are enabled. It is common for a CA to request inclusion with one of the trust bits enabled, and then later request that the other trust bit be enabled. The following steps outline how a CA may request to enable an additional trust bit for a root certificate that is included in NSS.<br />
<br />
# Do some initial preparations before you formally submit a request: <br />
#* Update the CP/CPS to reflect the policies for the additional trust bits, and make sure that the additions to the CP/CPS follow [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy]. <br />
#* Review [[CA/Required_or_Recommended_Practices|Required Practices]] and [[CA/Forbidden_or_Problematic_Practices|Forbidden Practices]].<br />
#* Have the annual audit cover the updated CP/CPS.<br />
#* Make sure that the audit and audit statements meet the requirements stated in [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits Mozilla's Root Store Policy].<br />
# Once you are ready, formally [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|submit your request]]<br />
#* Click on the "Create a new bug report" link in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|Application Instructions]]. <br />
#* Set the bug summary to "Enable trust bits for <name of your root>".<br />
#* Provide all of the required information by creating a [[CA/Information_Checklist#Create_a_Root_Inclusion_Case|Root Inclusion Case in the CCADB]].<br />
# The request will go through the [[CA/Application_Verification#Information_Verification|Information Verification]], [[CA/Application_Verification#Detailed_Review|Detailed Review]], [[CA/Application_Verification#Public_Discussion|Public Discussion]], and [[CA/Application_Verification#NSS_and_PSM_Bug_Creation|Inclusion]] phases as described in [[CA/Application_Process#Process_Overview|Application Process Overview]].<br />
<br />
== Enable EV ==<br />
<br />
The following steps outline the procedure for a CA to request that Extended Validation (EV) treatment be enabled for a root certificate that is currently included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS].<br />
<br />
# Do some initial preparations before you formally submit a request: <br />
#* Update the CP/CPS to reflect the EV policies, and make sure that the additions to the CP/CPS follow [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy] as well as the [https://cabforum.org/extended-validation/ CA/Browser Forum's EV SSL Certificate Guidelines]. <br />
#* Review [[CA/Required_or_Recommended_Practices|Required Practices]] and [[CA/Forbidden_or_Problematic_Practices|Forbidden Practices]].<br />
#* Complete an EV audit that meets the requirements stated in [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits Mozilla's Root Store Policy].<br />
# Once you are ready, formally [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|submit your request]]<br />
#* Click on the "Create a new bug report" link in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|Application Instructions]]. <br />
#* Set the bug summary to "Enable EV for <name of your root>"..<br />
#* Provide all of the required information by creating a [[CA/Information_Checklist#Create_a_Root_Inclusion_Case|Root Inclusion Case in the CCADB]].<br />
#* Run the [[PSM:EV_Testing_Easy_Version#EV-Readiness_Check|EV-Readiness Check]].<br />
# The request will go through the [[CA/Application_Verification#Information_Verification|Information Verification]], [[CA/Application_Verification#Detailed_Review|Detailed Review]], [[CA/Application_Verification#Public_Discussion|Public Discussion]], and [[CA/Application_Verification#NSS_and_PSM_Bug_Creation|Inclusion]] phases as described in [[CA/Application_Process#Process_Overview|Application Process Overview]].<br />
<br />
== Remove or Disable a Root ==<br />
Disabling a Root means one or more of the following:<br />
* Turn off trust bits (Websites, Email)<br />
* Turn off EV Treatment <br />
* Distrust certificates issued after a certain date (Distrust for TLS After, Distrust for S/MIME After)<br />
<br />
Reasons for removing or disabling a root certificate may include:<br />
* Security Compromise<br />
* Expired or Expiring CA <br />
* Small modulus key length<br />
* Outdated signing key algorithm<br />
* Transition/Rollover to new root completed <br />
* Legacy, no longer in use <br />
* No recent audit <br />
<br />
'''Important:''' Root changes that are motivated by a serious security concern such as a root compromise should be treated as a security-sensitive bug, and a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Security%20Vulnerability&groups=ca-program-security secure bug filed in Bugzilla].<br />
<br />
The process for removing or disabling a root in NSS is as follows:<br />
# Initiate the request:<br />
#* [https://bugzilla.mozilla.org/enter_bug.cgi?&component=CA%20Certificate%20Root%20Program&product=CA%20Program&short_desc=Remove%20%5Byour%20CA%27s%20name%5D%20root%20certificate%28s%29 File a bug in Bugzilla] with the following information:<br />
#** Product: CA Program<br />
#** Component: CA Certificate Root Program <br />
#** Summary should be one of: <br />
#*** Remove <CN or cert name> root cert<br />
#*** Turn off Trust Bit(s) for <CN or cert name> root cert <br />
#*** Turn off EV Treatment for <CN or cert name> root cert <br />
#*** Set Distrust After for <CN or cert name> root cert <br />
#** Description: Include the following information <br />
#*** Subject/Issuer field values in the root certificate to be changed<br />
#*** SHA256 Fingerprint of the certificate to be changed<br />
#*** Specify the change to be made. e.g. if the root is to be removed, or which trust bits are to be turned off, or the distrust-after dates<br />
#**** Consideration: For a serious situation, it might be better to disable the trust bits of that root, rather than just remove the root. If the root is removed, it could potentially be signed by another root that is included in NSS. However, if we disable the trust bits by default, then that root could not be used again for TLS in Firefox unless a user specifically turned on the websites trust bit for it.<br />
#*** Reason for requesting this change<br />
#*** Impact that the change may have on Mozilla users<br />
#* The bug may be marked as security-sensitive. Security-sensitive bugs can be viewed only by a select set of Bugzilla users, not by the general public.<br />
#** The security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update changing the trust bits of the root. <br />
#* In most situations an authoritative representative of the CA must request or approve the change. Mozilla reserves the right to approve the change without the consent of the CA. <br />
# The bug will be assigned to the Mozilla representative who is appointed to evaluate the request. This will usually be the [[Modules/Activities#CA_Certificates|CA Certificates Module Owner]].<br />
# The Mozilla representative will ensure the necessary information has been provided.<br />
#* Options should be identified <br />
#** Which trust bits to unset (Websites, Email)<br />
#** Whether the root certificate should be removed from NSS instead of unsetting trust bits<br />
#* Technical assistance may be requested<br />
#* Additional information may be requested of CA and other parties<br />
#* The Mozilla representative must confirm that a qualified representative has approved the change. A qualified representative is either<br />
#** The known representative of the CA, or<br />
#** Two Mozilla staff members, if the CA is not in agreement.<br />
# The Mozilla representative will deliver any preliminary decisions<br />
#* It may be necessary to treat the bug as a sensitive security issue and follow the [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla Policy for Handling Security Bugs]<br />
# Implementation<br />
#* If the resulting decision is to change the root certificate, the Mozilla representative will create a corresponding NSS bug to make the actual changes in NSS, and mark that bug as blocking the original change request.<br />
#* A Mozilla representative makes the changes in an [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] branch, and requests code review.<br />
#* A Mozilla representative commits the changes into NSS, and marks the bug RESOLVED FIXED.<br />
#* A Mozilla representative confirms the changes in Firefox Nightly, then updates the corresponding records in the [https://www.ccadb.org/ CCADB].<br />
#* For security-sensitive bugs, the security update will proceed as described in [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Policy for Handling Security Bugs]<br />
#* For non-security-sensitive requests, some time after the bug is marked as RESOLVED FIXED, various Mozilla products will move to using a version of NSS which contains the change. This process is mostly under the control of the release drivers for those products.<br />
# Notification <br />
#* The CA is responsible for providing appropriate notification to users who may be impacted by the change.<br />
#* For [http://www.mozilla.org/projects/security/security-bugs-policy.html Security-sensitive] requests the security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update removing the root.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Certificate_Change_Process&diff=1248937CA/Certificate Change Process2023-11-13T17:07:50Z<p>Bwilson: /* Remove or Disable a Root */ Changed guidance</p>
<hr />
<div>= Changing a Root Certificate that is Currently Included in NSS =<br />
<br />
This page describes how to change the default settings of a root certificate that is currently included in NSS. <br />
<br />
Reasons to change a root certificate in NSS may included, but are not limited to:<br />
<br />
* Security Compromise<br />
* Add a Trust Bit (one of Websites, Email)<br />
* Enable EV<br />
* Disable a Root (turn off one or more of the trust bits)<br />
* Remove a Root<br />
<br />
== Security Compromise ==<br />
<br />
When a serious security concern is noticed, such as a root compromise, it should be treated as a security-sensitive bug, and a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Security%20Vulnerability&groups=ca-program-security secure bug should be filed in Bugzilla].<br />
<br />
To report a concern about certificates being issued by a CA in Mozilla's Program:<br />
<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&version=other<br />
<br />
Open CA Mis-Issuance and other compliance bugs: https://wiki.mozilla.org/CA/Incident_Dashboard<br />
<br />
== Add a Trust Bit ==<br />
<br />
When a root certificate is included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS], one or more of the trust bits (websites, email) are enabled. It is common for a CA to request inclusion with one of the trust bits enabled, and then later request that the other trust bit be enabled. The following steps outline how a CA may request to enable an additional trust bit for a root certificate that is included in NSS.<br />
<br />
# Do some initial preparations before you formally submit a request: <br />
#* Update the CP/CPS to reflect the policies for the additional trust bits, and make sure that the additions to the CP/CPS follow [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy]. <br />
#* Review [[CA/Required_or_Recommended_Practices|Required Practices]] and [[CA/Forbidden_or_Problematic_Practices|Forbidden Practices]].<br />
#* Have the annual audit cover the updated CP/CPS.<br />
#* Make sure that the audit and audit statements meet the requirements stated in [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits Mozilla's Root Store Policy].<br />
# Once you are ready, formally [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|submit your request]]<br />
#* Click on the "Create a new bug report" link in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|Application Instructions]]. <br />
#* Set the bug summary to "Enable trust bits for <name of your root>".<br />
#* Provide all of the required information by creating a [[CA/Information_Checklist#Create_a_Root_Inclusion_Case|Root Inclusion Case in the CCADB]].<br />
# The request will go through the [[CA/Application_Verification#Information_Verification|Information Verification]], [[CA/Application_Verification#Detailed_Review|Detailed Review]], [[CA/Application_Verification#Public_Discussion|Public Discussion]], and [[CA/Application_Verification#NSS_and_PSM_Bug_Creation|Inclusion]] phases as described in [[CA/Application_Process#Process_Overview|Application Process Overview]].<br />
<br />
== Enable EV ==<br />
<br />
The following steps outline the procedure for a CA to request that Extended Validation (EV) treatment be enabled for a root certificate that is currently included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS].<br />
<br />
# Do some initial preparations before you formally submit a request: <br />
#* Update the CP/CPS to reflect the EV policies, and make sure that the additions to the CP/CPS follow [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy] as well as the [https://cabforum.org/extended-validation/ CA/Browser Forum's EV SSL Certificate Guidelines]. <br />
#* Review [[CA/Required_or_Recommended_Practices|Required Practices]] and [[CA/Forbidden_or_Problematic_Practices|Forbidden Practices]].<br />
#* Complete an EV audit that meets the requirements stated in [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits Mozilla's Root Store Policy].<br />
# Once you are ready, formally [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|submit your request]]<br />
#* Click on the "Create a new bug report" link in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|Application Instructions]]. <br />
#* Set the bug summary to "Enable EV for <name of your root>"..<br />
#* Provide all of the required information by creating a [[CA/Information_Checklist#Create_a_Root_Inclusion_Case|Root Inclusion Case in the CCADB]].<br />
#* Run the [[PSM:EV_Testing_Easy_Version#EV-Readiness_Check|EV-Readiness Check]].<br />
# The request will go through the [[CA/Application_Verification#Information_Verification|Information Verification]], [[CA/Application_Verification#Detailed_Review|Detailed Review]], [[CA/Application_Verification#Public_Discussion|Public Discussion]], and [[CA/Application_Verification#NSS_and_PSM_Bug_Creation|Inclusion]] phases as described in [[CA/Application_Process#Process_Overview|Application Process Overview]].<br />
<br />
== Remove or Disable a Root ==<br />
Disabling a Root means one or more of the following:<br />
* Turn off trust bits (Websites, Email)<br />
* Turn off EV Treatment <br />
* Distrust certificates issued after a certain date (Distrust for TLS After, Distrust for S/MIME After)<br />
<br />
Reasons for removing or disabling a root certificate may include:<br />
* Security Compromise<br />
* Expired or Expiring CA <br />
* Small modulus key length<br />
* Outdated signing key algorithm<br />
* Transition/Rollover to new root completed <br />
* Legacy, no longer in use <br />
* No recent audit <br />
<br />
'''Important:''' Root changes that are motivated by a serious security concern such as a root compromise should be treated as a security-sensitive bug, and a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&groups=crypto-core-security secure bug filed in Bugzilla].<br />
<br />
The process for removing or disabling a root in NSS is as follows:<br />
# Initiate the request:<br />
#* [https://bugzilla.mozilla.org/enter_bug.cgi?&component=CA%20Certificate%20Root%20Program&product=CA%20Program&bug_severity=enhancement&short_desc=Remove%20%5Byour%20CA%27s%20name%5D%20root%20certificate%28s%29 File a bug in Bugzilla] with the following information:<br />
#** Product: CA Program<br />
#** Component: CA Certificate Root Program <br />
#** Summary should be one of: <br />
#*** Remove <CN or cert name> root cert<br />
#*** Turn off Trust Bit(s) for <CN or cert name> root cert <br />
#*** Turn off EV Treatment for <CN or cert name> root cert <br />
#*** Set Distrust After for <CN or cert name> root cert <br />
#** Description: Include the following information <br />
#*** Subject/Issuer field values in the root certificate to be changed<br />
#*** SHA256 Fingerprint of the certificate to be changed<br />
#*** Specify the change to be made. e.g. if the root is to be removed, or which trust bits are to be turned off, or the distrust-after dates<br />
#**** Consideration: For a serious situation, it might be better to disable the trust bits of that root, rather than just remove the root. If the root is removed, it could potentially be signed by another root that is included in NSS. However, if we disable the trust bits by default, then that root could not be used again for TLS in Firefox unless a user specifically turned on the websites trust bit for it.<br />
#*** Reason for requesting this change<br />
#*** Impact that the change may have on Mozilla users<br />
#* The bug may be marked as security-sensitive. Security-sensitive bugs can be viewed only by a select set of Bugzilla users, not by the general public.<br />
#** The security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update changing the trust bits of the root. <br />
#* In most situations an authoritative representative of the CA must request or approve the change. Mozilla reserves the right to approve the change without the consent of the CA. <br />
# The bug will be assigned to the Mozilla representative who is appointed to evaluate the request. This will usually be the [[Modules/Activities#CA_Certificates|CA Certificates Module Owner]].<br />
# The Mozilla representative will ensure the necessary information has been provided.<br />
#* Options should be identified <br />
#** Which trust bits to unset (Websites, Email)<br />
#** Whether the root certificate should be removed from NSS instead of unsetting trust bits<br />
#* Technical assistance may be requested<br />
#* Additional information may be requested of CA and other parties<br />
#* The Mozilla representative must confirm that a qualified representative has approved the change. A qualified representative is either<br />
#** The known representative of the CA, or<br />
#** Two Mozilla staff members, if the CA is not in agreement.<br />
# The Mozilla representative will deliver any preliminary decisions<br />
#* It may be necessary to treat the bug as a sensitive security issue and follow the [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla Policy for Handling Security Bugs]<br />
# Implementation<br />
#* If the resulting decision is to change the root certificate, the Mozilla representative will create a corresponding NSS bug to make the actual changes in NSS, and mark that bug as blocking the original change request.<br />
#* A Mozilla representative makes the changes in an [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] branch, and requests code review.<br />
#* A Mozilla representative commits the changes into NSS, and marks the bug RESOLVED FIXED.<br />
#* A Mozilla representative confirms the changes in Firefox Nightly, then updates the corresponding records in the [https://www.ccadb.org/ CCADB].<br />
#* For security-sensitive bugs, the security update will proceed as described in [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Policy for Handling Security Bugs]<br />
#* For non-security-sensitive requests, some time after the bug is marked as RESOLVED FIXED, various Mozilla products will move to using a version of NSS which contains the change. This process is mostly under the control of the release drivers for those products.<br />
# Notification <br />
#* The CA is responsible for providing appropriate notification to users who may be impacted by the change.<br />
#* For [http://www.mozilla.org/projects/security/security-bugs-policy.html Security-sensitive] requests the security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update removing the root.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1248821CA/Vulnerability Disclosure2023-11-01T22:39:22Z<p>Bwilson: /* How to Disclose a Reportable Vulnerability */ Minor edit</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents to Mozilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report], as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
Ensure that you report security incidents to other root stores as well. Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla. (People cc:'ed in the bug have access to view the bug, so review the cc: list to ensure that no unintended people are in that list.)<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Security Incidents include the following:'''<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Malware infections, ransomware, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the duration of the vulnerability/incident, identity of threat actors, nature of the compromise, and the specific systems, infrastructure, or processes affected. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]. <br />
<br />
==== Severity / Impact Assessment ====<br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on certificate holders, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services;<br />
<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
3. Summarize the steps taken to address the root cause(s) and to strengthen security controls to prevent a similar vulnerability/incident in the future;<br />
<br />
4. Detail any other steps being taken to mitigate the effects of the vulnerabilities/incident, including the status of each action, and the date each action will be completed; and<br />
<br />
5. Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
# Outline the remediation plan and actions taken to address the incident or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation steps you are taking to resolve the situation and ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1248820CA/Vulnerability Disclosure2023-11-01T22:38:54Z<p>Bwilson: /* How to Disclose a Reportable Vulnerability */ Added warning about cc: list</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents to Mozilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report], as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
Ensure that you report security incidents to other root stores as well. Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla. (People cc:'ed in the bug have access to view the bug, so review the cc: list to ensure that no unintended people are in that list.)<br />
Also,<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Security Incidents include the following:'''<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Malware infections, ransomware, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the duration of the vulnerability/incident, identity of threat actors, nature of the compromise, and the specific systems, infrastructure, or processes affected. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]. <br />
<br />
==== Severity / Impact Assessment ====<br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on certificate holders, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services;<br />
<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
3. Summarize the steps taken to address the root cause(s) and to strengthen security controls to prevent a similar vulnerability/incident in the future;<br />
<br />
4. Detail any other steps being taken to mitigate the effects of the vulnerabilities/incident, including the status of each action, and the date each action will be completed; and<br />
<br />
5. Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
# Outline the remediation plan and actions taken to address the incident or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation steps you are taking to resolve the situation and ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1248819CA/Vulnerability Disclosure2023-11-01T22:16:49Z<p>Bwilson: /* How to Disclose a Reportable Vulnerability */ Added notice about other root stores.</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents to Mozilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report], as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
Ensure that you report security incidents to other root stores as well. Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla.<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Security Incidents include the following:'''<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Malware infections, ransomware, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the duration of the vulnerability/incident, identity of threat actors, nature of the compromise, and the specific systems, infrastructure, or processes affected. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]. <br />
<br />
==== Severity / Impact Assessment ====<br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on certificate holders, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services;<br />
<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
3. Summarize the steps taken to address the root cause(s) and to strengthen security controls to prevent a similar vulnerability/incident in the future;<br />
<br />
4. Detail any other steps being taken to mitigate the effects of the vulnerabilities/incident, including the status of each action, and the date each action will be completed; and<br />
<br />
5. Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
# Outline the remediation plan and actions taken to address the incident or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation steps you are taking to resolve the situation and ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Vulnerability_Disclosure&diff=1248718CA/Vulnerability Disclosure2023-10-25T18:23:37Z<p>Bwilson: /* How to Disclose a Reportable Vulnerability */ Added image</p>
<hr />
<div>== Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store ==<br />
<br />
=== Purpose ===<br />
<br />
To provide Mozilla with:<br />
* Information about security compromises that require action from Mozilla; <br />
* Security-sensitive information that needs to be shared with Mozilla.<br />
<br />
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. '''A Reportable Vulnerability is ''either'' a security vulnerability ''or'' a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates.''' (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.) <br />
<br />
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party. <br />
<br />
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents to Mozilla.<br />
<br />
=== How to Disclose a Reportable Vulnerability ===<br />
<br />
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report public-facing Incident Report], as required by section 2.4 of Mozilla’s Root Store Policy. <br />
<br />
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla: <br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program<br />
<br />
or<br />
<br />
https://bugzilla.mozilla.org/enter_bug.cgi<br />
<br />
Product: CA Program<br />
<br />
Component: CA Security Vulnerability<br />
<br />
'''Make sure you check the box “CA Program Security”''' under “Only users in all of the selected groups can view this bug”.<br />
<br />
[[File:CA-Security-Bug.png|300px]]<br />
<br />
=== Types of Vulnerabilities/Incidents to be disclosed ===<br />
<br />
Vulnerabilities/incidents that may “significantly impact the confidentiality, integrity, or availability” of a CA's internal systems, regardless of direct impact on certificate issuance, must be reported if they pose ongoing risk to the overall integrity and security of CA operations. This includes significant impact not just to issuing systems, but also to network and server security, internal software, and the availability and reliability of certificate status services, such as CRLs and OCSP. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.<br />
<br />
'''Security Incidents include the following:'''<br />
<br />
* Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information). <br />
* Malware infections, ransomware, or other data integrity issues that irrecoverably damage or compromise sensitive CA data. <br />
* Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates. <br />
<br />
'''The following are NOT ordinarily considered to be Reportable Vulnerabilities:'''<br />
<br />
* Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.<br />
* Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.<br />
* Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.<br />
* Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.<br />
* Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.<br />
* Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.<br />
* Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.<br />
<br />
=== Vulnerability/Incident Response Expectations ===<br />
<br />
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:<br />
<br />
* Evidence gathering and forensic analysis<br />
* Containment<br />
* Determining vulnerability/incident significance<br />
* Notification of root store operators and other important stakeholders<br />
* System restoration and system integrity<br />
* Root cause analysis<br />
* Security hardening with patches, updates, or configuration changes<br />
* Ongoing remediation<br />
<br />
For additional guidance, see sources such as [https://www.enisa.europa.eu/topics/incident-response ENISA], [https://www.cisecurity.org/controls/incident-response-management CIS Security], [https://cert.europa.eu/ CERT.EU], [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf NIST], [https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-and-cyber-safety/cybersecurity-incident-response CISA.gov] and [https://www.iso.org/standard/78973.html ISO/IEC 27035-1:2023].<br />
<br />
=== Determining Significance ===<br />
<br />
Factors to consider in determining the significance or severity of a vulnerability/incident should include:<br />
<br />
* the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;<br />
* number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;<br />
* duration (e.g. the date and time when the vulnerability/incident began and when it ended);<br />
* potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);<br />
* potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;<br />
* nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);<br />
* sensitivity of the information threatened;<br />
* potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and<br />
* escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).<br />
<br />
Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].<br />
<br />
=== Reportable Vulnerability Disclosure Contents ===<br />
<br />
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.<br />
<br />
==== Concise Summary ====<br />
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.<br />
<br />
==== Vulnerability/Incident Details ====<br />
# Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident. <br />
# Type and Detailed Description, including the duration of the vulnerability/incident, identity of threat actors, nature of the compromise, and the specific systems, infrastructure, or processes affected. <br />
# Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]. <br />
<br />
==== Severity / Impact Assessment ====<br />
Summarize the following: <br />
# the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;<br />
# number and type(s) of certificates affected, if applicable;<br />
# the potential impact on certificate holders, relying parties, and other stakeholders; and<br />
# the escalation potential.<br />
<br />
==== Response and Mitigation ====<br />
# State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.<br />
# Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services;<br />
<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
<br />
3. Summarize the steps taken to address the root cause(s) and to strengthen security controls to prevent a similar vulnerability/incident in the future;<br />
<br />
4. Detail any other steps being taken to mitigate the effects of the vulnerabilities/incident, including the status of each action, and the date each action will be completed; and<br />
<br />
5. Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.<br />
<br />
==== CA Remediation Measures ====<br />
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]: <br />
# Outline the remediation plan and actions taken to address the incident or identified vulnerabilities, weaknesses, or gaps in security controls;<br />
# Specify the remediation steps you are taking to resolve the situation and ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, its current status of implementation, and the date that each step will be completed; and<br />
# Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.<br />
<br />
==== Contact Information ====<br />
Provide contact information for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=File:CA-Security-Bug.png&diff=1248717File:CA-Security-Bug.png2023-10-25T18:13:25Z<p>Bwilson: </p>
<hr />
<div></div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Certificate_Change_Process&diff=1248716CA/Certificate Change Process2023-10-25T18:02:02Z<p>Bwilson: /* Security Compromise */ Changed URL to Bugzilla</p>
<hr />
<div>= Changing a Root Certificate that is Currently Included in NSS =<br />
<br />
This page describes how to change the default settings of a root certificate that is currently included in NSS. <br />
<br />
Reasons to change a root certificate in NSS may included, but are not limited to:<br />
<br />
* Security Compromise<br />
* Add a Trust Bit (one of Websites, Email)<br />
* Enable EV<br />
* Disable a Root (turn off one or more of the trust bits)<br />
* Remove a Root<br />
<br />
== Security Compromise ==<br />
<br />
When a serious security concern is noticed, such as a root compromise, it should be treated as a security-sensitive bug, and a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Security%20Vulnerability&groups=ca-program-security secure bug should be filed in Bugzilla].<br />
<br />
To report a concern about certificates being issued by a CA in Mozilla's Program:<br />
<br />
* https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&version=other<br />
<br />
Open CA Mis-Issuance and other compliance bugs: https://wiki.mozilla.org/CA/Incident_Dashboard<br />
<br />
== Add a Trust Bit ==<br />
<br />
When a root certificate is included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS], one or more of the trust bits (websites, email) are enabled. It is common for a CA to request inclusion with one of the trust bits enabled, and then later request that the other trust bit be enabled. The following steps outline how a CA may request to enable an additional trust bit for a root certificate that is included in NSS.<br />
<br />
# Do some initial preparations before you formally submit a request: <br />
#* Update the CP/CPS to reflect the policies for the additional trust bits, and make sure that the additions to the CP/CPS follow [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy]. <br />
#* Review [[CA/Required_or_Recommended_Practices|Required Practices]] and [[CA/Forbidden_or_Problematic_Practices|Forbidden Practices]].<br />
#* Have the annual audit cover the updated CP/CPS.<br />
#* Make sure that the audit and audit statements meet the requirements stated in [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits Mozilla's Root Store Policy].<br />
# Once you are ready, formally [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|submit your request]]<br />
#* Click on the "Create a new bug report" link in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|Application Instructions]]. <br />
#* Set the bug summary to "Enable trust bits for <name of your root>".<br />
#* Provide all of the required information by creating a [[CA/Information_Checklist#Create_a_Root_Inclusion_Case|Root Inclusion Case in the CCADB]].<br />
# The request will go through the [[CA/Application_Verification#Information_Verification|Information Verification]], [[CA/Application_Verification#Detailed_Review|Detailed Review]], [[CA/Application_Verification#Public_Discussion|Public Discussion]], and [[CA/Application_Verification#NSS_and_PSM_Bug_Creation|Inclusion]] phases as described in [[CA/Application_Process#Process_Overview|Application Process Overview]].<br />
<br />
== Enable EV ==<br />
<br />
The following steps outline the procedure for a CA to request that Extended Validation (EV) treatment be enabled for a root certificate that is currently included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS].<br />
<br />
# Do some initial preparations before you formally submit a request: <br />
#* Update the CP/CPS to reflect the EV policies, and make sure that the additions to the CP/CPS follow [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy] as well as the [https://cabforum.org/extended-validation/ CA/Browser Forum's EV SSL Certificate Guidelines]. <br />
#* Review [[CA/Required_or_Recommended_Practices|Required Practices]] and [[CA/Forbidden_or_Problematic_Practices|Forbidden Practices]].<br />
#* Complete an EV audit that meets the requirements stated in [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits Mozilla's Root Store Policy].<br />
# Once you are ready, formally [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|submit your request]]<br />
#* Click on the "Create a new bug report" link in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|Application Instructions]]. <br />
#* Set the bug summary to "Enable EV for <name of your root>"..<br />
#* Provide all of the required information by creating a [[CA/Information_Checklist#Create_a_Root_Inclusion_Case|Root Inclusion Case in the CCADB]].<br />
#* Run the [[PSM:EV_Testing_Easy_Version#EV-Readiness_Check|EV-Readiness Check]].<br />
# The request will go through the [[CA/Application_Verification#Information_Verification|Information Verification]], [[CA/Application_Verification#Detailed_Review|Detailed Review]], [[CA/Application_Verification#Public_Discussion|Public Discussion]], and [[CA/Application_Verification#NSS_and_PSM_Bug_Creation|Inclusion]] phases as described in [[CA/Application_Process#Process_Overview|Application Process Overview]].<br />
<br />
== Remove or Disable a Root ==<br />
Disabling a Root means one or more of the following:<br />
* Turn off trust bits (Websites, Email)<br />
* Turn off EV Treatment <br />
* Distrust certificates issued after a certain date (Distrust for TLS After, Distrust for S/MIME After)<br />
<br />
Reasons for removing or disabling a root certificate may include:<br />
* Security Compromise<br />
* Expired or Expiring CA <br />
* Small modulus key length<br />
* Outdated signing key algorithm<br />
* Transition/Rollover to new root completed <br />
* Legacy, no longer in use <br />
* No recent audit <br />
<br />
'''Important:''' Root changes that are motivated by a serious security concern such as a root compromise should be treated as a security-sensitive bug, and a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&groups=crypto-core-security secure bug filed in Bugzilla].<br />
<br />
The process for removing or disabling a root in NSS is as follows:<br />
# Initiate the request:<br />
#* [https://bugzilla.mozilla.org/enter_bug.cgi?&component=CA%20Certificate%20Root%20Program&product=CA%20Program&bug_severity=enhancement&short_desc=Add%20%5Byour%20CA%27s%20name%5D%20root%20certificate%28s%29 File a bug in Bugzilla] with the following information:<br />
#** Product: CA Program<br />
#** Component: CA Certificate Root Program <br />
#** Summary should be one of: <br />
#*** Remove <CN or cert name> root cert<br />
#*** Turn off Trust Bit(s) for <CN or cert name> root cert <br />
#*** Turn off EV Treatment for <CN or cert name> root cert <br />
#*** Set Distrust After for <CN or cert name> root cert <br />
#** Description: Include the following information <br />
#*** Subject/Issuer field values in the root certificate to be changed<br />
#*** SHA256 Fingerprint of the certificate to be changed<br />
#*** Specify the change to be made. e.g. if the root is to be removed, or which trust bits are to be turned off, or the distrust-after dates<br />
#**** Consideration: For a serious situation, it might be better to disable the trust bits of that root, rather than just remove the root. If the root is removed, it could potentially be signed by another root that is included in NSS. However, if we disable the trust bits by default, then that root could not be used again for TLS in Firefox unless a user specifically turned on the websites trust bit for it.<br />
#*** Reason for requesting this change<br />
#*** Impact that the change may have on Mozilla users<br />
#* The bug may be marked as security-sensitive. Security-sensitive bugs can be viewed only by a select set of Bugzilla users, not by the general public.<br />
#** The security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update changing the trust bits of the root. <br />
#* In most situations an authoritative representative of the CA must request or approve the change. Mozilla reserves the right to approve the change without the consent of the CA. <br />
# The bug will be assigned to the Mozilla representative who is appointed to evaluate the request. This will usually be the [[Modules/Activities#CA_Certificates|CA Certificates Module Owner]].<br />
# The Mozilla representative will ensure the necessary information has been provided.<br />
#* Options should be identified <br />
#** Which trust bits to unset (Websites, Email)<br />
#** Whether the root certificate should be removed from NSS instead of unsetting trust bits<br />
#* Technical assistance may be requested<br />
#* Additional information may be requested of CA and other parties<br />
#* The Mozilla representative must confirm that a qualified representative has approved the change. A qualified representative is either<br />
#** The known representative of the CA, or<br />
#** Two Mozilla staff members, if the CA is not in agreement.<br />
# The Mozilla representative will deliver any preliminary decisions<br />
#* It may be necessary to treat the bug as a sensitive security issue and follow the [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla Policy for Handling Security Bugs]<br />
# Implementation<br />
#* If the resulting decision is to change the root certificate, the Mozilla representative will create a corresponding NSS bug to make the actual changes in NSS, and mark that bug as blocking the original change request.<br />
#* A Mozilla representative makes the changes in an [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] branch, and requests code review.<br />
#* A Mozilla representative commits the changes into NSS, and marks the bug RESOLVED FIXED.<br />
#* A Mozilla representative confirms the changes in Firefox Nightly, then updates the corresponding records in the [https://www.ccadb.org/ CCADB].<br />
#* For security-sensitive bugs, the security update will proceed as described in [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Policy for Handling Security Bugs]<br />
#* For non-security-sensitive requests, some time after the bug is marked as RESOLVED FIXED, various Mozilla products will move to using a version of NSS which contains the change. This process is mostly under the control of the release drivers for those products.<br />
# Notification <br />
#* The CA is responsible for providing appropriate notification to users who may be impacted by the change.<br />
#* For [http://www.mozilla.org/projects/security/security-bugs-policy.html Security-sensitive] requests the security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update removing the root.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Responding_To_An_Incident&diff=1248623CA/Responding To An Incident2023-10-17T22:10:41Z<p>Bwilson: /* Examples of Good Practice */ Added space and bolded</p>
<hr />
<div>Please go to '''https://www.ccadb.org/cas/incident-report''' for detailed information about reporting compliance incidents.<br />
<br />
(Researchers who report CA incidents such as misissuances are welcome to include a link to that page in their report to the CA, reminding the CA of Mozilla's expectations for incident reporting.) <br />
<br />
This page provides supplemental information on Mozilla's expectations regarding the handling of compliance incidents, incident reporting, remediation, and communication. It gives guidance to CAs as to how Mozilla expects them to react to reported incidents such as misissuances, and what the best practices are. <br />
<br />
= Overview = <br />
<br />
An incident arises any time a CA fails to comply with an applicable requirement found in the Mozilla Root Store Policy, the CA/Browser Forum's requirements, or the CCADB's requirements. As noted in section 2.4 of the Mozilla Root Store Policy, a compliance incident can arise from certificate misissuance, delayed revocation, procedural or operational issues, or some other cause. <br />
<br />
A "misissuance" is defined as any certificate issued in contravention of any applicable standard, process or document - so it could be RFC non-compliant, BR non-compliant, issued contrary to the CA's CP/CPS, or have some other flaw or problem. <br />
<br />
Sometimes our guidance is framed in terms of misissuance of certificates; it will need to be adapted as necessary for incidents of a different nature, respecting the spirit of the information requests contained in the standard incident-reporting template.<br />
<br />
Other examples of incidents include misconfigured CRLs and OCSP responders, delayed responses, failures to properly communicate information, and any other event affecting trust in the WebPKI which does not involve the actual contents of certificates.<br />
<br />
While some forms of incident may be seen as less serious than others, opinions may vary. Mozilla sees all incidents as good opportunities for CA operators to confirm that their incident response processes are working well, and so we expect a similar level of timeliness of response and quality of reporting for all incidents, whatever their adjudged severity.<br />
<br />
To be clear, the [https://www.ccadb.org/cas/incident-report#incident-report-template incident reporting template] and incident-reporting process provide a set of best practices. Therefore, failure to follow one or more of the recommendations alone is not by itself sanctionable. However, failure to do so without good reason may affect Mozilla's general opinion of the CA. Our confidence in a CA is in part affected by the number and severity of incidents, but it is also significantly affected by the speed and quality of incident response. <br />
<br />
= Immediate Actions =<br />
<br />
In misissuance cases, a CA should almost always immediately cease issuance from the affected part of its PKI. In situations not involving misissuance, there also may be processes that need to be stopped until the CA has diagnosed the source of the problem.<br />
<br />
Once the problem is diagnosed, if the CA is able to put in place temporary or manual procedures to prevent the problem from re-occurring, it may restart the process even if a full fix is not rolled out. CAs should not restart affected processes until they are confident that the problem will not re-occur.<br />
<br />
'''An initial report should be filed within 72 hours of being made aware of the incident.'''<br />
See https://www.ccadb.org/cas/incident-report#incident-reports <br />
<br />
= Revocation =<br />
<br />
It is normal practice for CAs to revoke misissued or otherwise problematic certificates. But that leaves the question about '''when''' this should be done, particularly if it's not possible to contact the customer immediately, or if they are unable to replace their certificate quickly. CAs should ensure that they are complying with Sections 4.9.1 through 4.9.5 of '''[https://cabforum.org/baseline-requirements-documents/ the CA/Browser Forum’s Baseline Requirements]'''. <br />
<br />
This means that, in most cases of misissuance, the CA has an obligation under the BRs to revoke the certificates concerned within 24 hours, or 5 days in some cases.<br />
<br />
Mozilla recognizes that in some '''exceptional''' circumstances, revoking the affected certificates within the prescribed deadline may cause significant harm, such as when the certificate is used in critical infrastructure and cannot be safely replaced prior to the revocation deadline, or when the volume of revocations in a short period of time would result in a large cumulative impact to the web. However, Mozilla does not grant exceptions to the BR revocation requirements. It is our position that your CA is ultimately responsible for deciding if the harm caused by following the requirements of the Baseline Requirements outweighs the risks that are passed on to individuals who rely on the web PKI by choosing not to meet this requirement.<br />
<br />
If your CA will not be revoking the certificates within the time period required by the BRs, our expectations are that:<br />
<br />
* A separate incident report will be filed in Bugzilla.<br />
* The decision and rationale for delaying revocation will be disclosed in the form of a preliminary incident report immediately; preferably before the BR-mandated revocation deadline. The rationale must include detailed and substantiated explanations for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.<br />
* Any decision to not comply with the timeline specified in the Baseline Requirements must also be accompanied by a clear timeline describing if and when the problematic certificates will be revoked or expire naturally, and supported by the rationale to delay revocation.<br />
* The issue will need to be listed as a finding in your CA’s next BR audit statement.<br />
* Your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable.<br />
* You will perform an analysis to determine the factors that prevented timely revocation of the certificates, and include a set of remediation actions in the final incident report that aim to prevent future revocation delays.<br />
<br />
If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.<br />
<br />
= Follow-Up Actions =<br />
<br />
* Work out how the bug or problem was introduced. For a code bug, were the code review processes sufficient? Does your code have automated tests, and if so, why did they not catch this case?<br />
<br />
* Work out why the problem was not detected earlier. Were these certificates missed by your linting processes or self audits? Or is the code or process you use for insufficient?<br />
<br />
* If the problem is lack of compliance to an RFC, Baseline Requirement, or Mozilla Policy requirement: were you aware of this requirement? If not, why not? If so, was an attempt made to meet it? If not, why not? If so, why was that attempt flawed? Do any processes need updating for making sure your CA complies with the latest version of the various requirements placed upon it?<br />
<br />
* Scan your corpus of certificates to look for others with the same issue. It does not look good for a CA to claim they have revoked all affected certificates and resolved the issue, and then for a researcher to discover another set of certificates with the same or a similar problem.<br />
<br />
* Examine whether there are potential related problems which you can also remediate at the same time. For example, if the problem was bad data in a particular field, consider improving the validation of all fields in the certificate prior to issuance. You should be proactively looking for ways, such as pre-issuance lint testing, to harden your issuance pipeline against further problems.<br />
<br />
* If, as happens in a regrettably large number of cases, a problem report was sent to your CA but action in accordance with BR section 9.4.5 was not taken within 24 hours, investigate what happened to that report and whether your report handling processes are adequate.<br />
<br />
= Incident Report =<br />
<br />
For guidance on incident reporting, first visit '''https://www.ccadb.org/cas/incident-report'''.<br />
<br />
Your CA must submit an incident report by [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&version=other creating a bug in Bugzilla under the CA Program :: CA Certificate Compliance component]. When the incident is reported only on the CCADB public list or on the [https://groups.google.com/a/mozilla.org/g/dev-security-policy MDSP mailing list], then a bug will be created to track the incident and its resolution in Bugzilla. CAs are encouraged to announce important incidents on public@ccadb.org when they involve the Baseline Requirements, other root programs, or the CCADB; or on the Mozilla dev-security-policy list, when they only involve violations of the Mozilla Root Store Policy. <br />
<br />
The incident report should use the markdown template provided on the CCADB website:<br />
<br />
'''https://www.ccadb.org/cas/incident-report#incident-report-template''' <br />
<br />
= Keeping Us Informed =<br />
<br />
Once the report is posted, you should respond promptly to questions that are asked, and in no circumstances should a question linger without a response for more than one week, even if the response is only to acknowledge the question and provide a later date when an answer will be delivered. You should also provide updates at least every week giving your progress, and confirm when the remediation steps have been completed - unless a root store representative has agreed to a different schedule by setting a “Next Update” date in the “Whiteboard” field of the bug or has announced they consider closing the bug and no further comments have been posted. Updates to important incidents (see e.g. https://www.ccadb.org/cas/public-group#lessons-learned-from-ca-incident-reports) should be posted to either the [https://groups.google.com/a/ccadb.org/g/public CCADB Public list] or the [https://groups.google.com/a/mozilla.org/g/dev-security-policy MDSP mailing list] and the Bugzilla bug. The bug will be closed when remediation is completed.<br />
<br />
= Examples of Good Practice =<br />
<br />
Here are some examples of good practice, where a CA did most or all of the things recommended above. <br />
<br />
'''Note that these incident reports conformed to an earlier version of the incident reporting template.'''<br />
<br />
== Let's Encrypt Unicode Normalization Compliance Incident ==<br />
<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/g6_zGA2exXw Initial Public Problem Report], 2017-08-10 20:23 UTC (apparently LE were made aware of the problem privately earlier that day)<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/g6_zGA2exXw/_tXldrbIBwAJ Initial Public Response from CA], 2017-08-10 21:53 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/nMxaxhYb_iY/AmjCI3_ZBwAJY Final Report from CA], 2017-08-11 03:00 UTC<br />
<br />
In this case, the CA managed to diagnose the problem, remediate it, and deploy the fix to production within 24 hours.<br />
<br />
== PKIOverheid Short Serial Number Incident ==<br />
<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ Initial Public Problem Report], 2017-07-18 22:26 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/TzH5eI9dAQAJ Initial Public Response from CA], 2017-07-25 19:20 UTC<br />
* [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ Final Report from CA], 2017-08-11 14:39 UTC<br />
<br />
While the CA could have provided interim updates, and the final report was a little delayed, the contents of it were excellent.<br />
<br />
== SecureTrust "Some-State" in stateOrProvinceName ==<br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374 Initial Public Problem Report], 2019-05-14 00:49 UTC<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374#c1 Initial Public Response from CA], 2017-05-15 19:40 UTC<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374#c8 Final Report from CA], 2017-06-14 9:43 UTC<br />
<br />
The level of detail provided by the CA in both the initial report and follow-up responses is comprehensive, as is the work performed to identify additional occurrences and to remediate the issue.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Responding_To_An_Incident&diff=1248622CA/Responding To An Incident2023-10-17T22:08:10Z<p>Bwilson: Additional changes to reference CCADB incident reporting</p>
<hr />
<div>Please go to '''https://www.ccadb.org/cas/incident-report''' for detailed information about reporting compliance incidents.<br />
<br />
(Researchers who report CA incidents such as misissuances are welcome to include a link to that page in their report to the CA, reminding the CA of Mozilla's expectations for incident reporting.) <br />
<br />
This page provides supplemental information on Mozilla's expectations regarding the handling of compliance incidents, incident reporting, remediation, and communication. It gives guidance to CAs as to how Mozilla expects them to react to reported incidents such as misissuances, and what the best practices are. <br />
<br />
= Overview = <br />
<br />
An incident arises any time a CA fails to comply with an applicable requirement found in the Mozilla Root Store Policy, the CA/Browser Forum's requirements, or the CCADB's requirements. As noted in section 2.4 of the Mozilla Root Store Policy, a compliance incident can arise from certificate misissuance, delayed revocation, procedural or operational issues, or some other cause. <br />
<br />
A "misissuance" is defined as any certificate issued in contravention of any applicable standard, process or document - so it could be RFC non-compliant, BR non-compliant, issued contrary to the CA's CP/CPS, or have some other flaw or problem. <br />
<br />
Sometimes our guidance is framed in terms of misissuance of certificates; it will need to be adapted as necessary for incidents of a different nature, respecting the spirit of the information requests contained in the standard incident-reporting template.<br />
<br />
Other examples of incidents include misconfigured CRLs and OCSP responders, delayed responses, failures to properly communicate information, and any other event affecting trust in the WebPKI which does not involve the actual contents of certificates.<br />
<br />
While some forms of incident may be seen as less serious than others, opinions may vary. Mozilla sees all incidents as good opportunities for CA operators to confirm that their incident response processes are working well, and so we expect a similar level of timeliness of response and quality of reporting for all incidents, whatever their adjudged severity.<br />
<br />
To be clear, the [https://www.ccadb.org/cas/incident-report#incident-report-template incident reporting template] and incident-reporting process provide a set of best practices. Therefore, failure to follow one or more of the recommendations alone is not by itself sanctionable. However, failure to do so without good reason may affect Mozilla's general opinion of the CA. Our confidence in a CA is in part affected by the number and severity of incidents, but it is also significantly affected by the speed and quality of incident response. <br />
<br />
= Immediate Actions =<br />
<br />
In misissuance cases, a CA should almost always immediately cease issuance from the affected part of its PKI. In situations not involving misissuance, there also may be processes that need to be stopped until the CA has diagnosed the source of the problem.<br />
<br />
Once the problem is diagnosed, if the CA is able to put in place temporary or manual procedures to prevent the problem from re-occurring, it may restart the process even if a full fix is not rolled out. CAs should not restart affected processes until they are confident that the problem will not re-occur.<br />
<br />
'''An initial report should be filed within 72 hours of being made aware of the incident.'''<br />
See https://www.ccadb.org/cas/incident-report#incident-reports <br />
<br />
= Revocation =<br />
<br />
It is normal practice for CAs to revoke misissued or otherwise problematic certificates. But that leaves the question about '''when''' this should be done, particularly if it's not possible to contact the customer immediately, or if they are unable to replace their certificate quickly. CAs should ensure that they are complying with Sections 4.9.1 through 4.9.5 of '''[https://cabforum.org/baseline-requirements-documents/ the CA/Browser Forum’s Baseline Requirements]'''. <br />
<br />
This means that, in most cases of misissuance, the CA has an obligation under the BRs to revoke the certificates concerned within 24 hours, or 5 days in some cases.<br />
<br />
Mozilla recognizes that in some '''exceptional''' circumstances, revoking the affected certificates within the prescribed deadline may cause significant harm, such as when the certificate is used in critical infrastructure and cannot be safely replaced prior to the revocation deadline, or when the volume of revocations in a short period of time would result in a large cumulative impact to the web. However, Mozilla does not grant exceptions to the BR revocation requirements. It is our position that your CA is ultimately responsible for deciding if the harm caused by following the requirements of the Baseline Requirements outweighs the risks that are passed on to individuals who rely on the web PKI by choosing not to meet this requirement.<br />
<br />
If your CA will not be revoking the certificates within the time period required by the BRs, our expectations are that:<br />
<br />
* A separate incident report will be filed in Bugzilla.<br />
* The decision and rationale for delaying revocation will be disclosed in the form of a preliminary incident report immediately; preferably before the BR-mandated revocation deadline. The rationale must include detailed and substantiated explanations for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.<br />
* Any decision to not comply with the timeline specified in the Baseline Requirements must also be accompanied by a clear timeline describing if and when the problematic certificates will be revoked or expire naturally, and supported by the rationale to delay revocation.<br />
* The issue will need to be listed as a finding in your CA’s next BR audit statement.<br />
* Your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable.<br />
* You will perform an analysis to determine the factors that prevented timely revocation of the certificates, and include a set of remediation actions in the final incident report that aim to prevent future revocation delays.<br />
<br />
If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.<br />
<br />
= Follow-Up Actions =<br />
<br />
* Work out how the bug or problem was introduced. For a code bug, were the code review processes sufficient? Does your code have automated tests, and if so, why did they not catch this case?<br />
<br />
* Work out why the problem was not detected earlier. Were these certificates missed by your linting processes or self audits? Or is the code or process you use for insufficient?<br />
<br />
* If the problem is lack of compliance to an RFC, Baseline Requirement, or Mozilla Policy requirement: were you aware of this requirement? If not, why not? If so, was an attempt made to meet it? If not, why not? If so, why was that attempt flawed? Do any processes need updating for making sure your CA complies with the latest version of the various requirements placed upon it?<br />
<br />
* Scan your corpus of certificates to look for others with the same issue. It does not look good for a CA to claim they have revoked all affected certificates and resolved the issue, and then for a researcher to discover another set of certificates with the same or a similar problem.<br />
<br />
* Examine whether there are potential related problems which you can also remediate at the same time. For example, if the problem was bad data in a particular field, consider improving the validation of all fields in the certificate prior to issuance. You should be proactively looking for ways, such as pre-issuance lint testing, to harden your issuance pipeline against further problems.<br />
<br />
* If, as happens in a regrettably large number of cases, a problem report was sent to your CA but action in accordance with BR section 9.4.5 was not taken within 24 hours, investigate what happened to that report and whether your report handling processes are adequate.<br />
<br />
= Incident Report =<br />
<br />
For guidance on incident reporting, first visit '''https://www.ccadb.org/cas/incident-report'''.<br />
<br />
Your CA must submit an incident report by [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&version=other creating a bug in Bugzilla under the CA Program :: CA Certificate Compliance component]. When the incident is reported only on the CCADB public list or on the [https://groups.google.com/a/mozilla.org/g/dev-security-policy MDSP mailing list], then a bug will be created to track the incident and its resolution in Bugzilla. CAs are encouraged to announce important incidents on public@ccadb.org when they involve the Baseline Requirements, other root programs, or the CCADB; or on the Mozilla dev-security-policy list, when they only involve violations of the Mozilla Root Store Policy. <br />
<br />
The incident report should use the markdown template provided on the CCADB website:<br />
<br />
'''https://www.ccadb.org/cas/incident-report#incident-report-template''' <br />
<br />
= Keeping Us Informed =<br />
<br />
Once the report is posted, you should respond promptly to questions that are asked, and in no circumstances should a question linger without a response for more than one week, even if the response is only to acknowledge the question and provide a later date when an answer will be delivered. You should also provide updates at least every week giving your progress, and confirm when the remediation steps have been completed - unless a root store representative has agreed to a different schedule by setting a “Next Update” date in the “Whiteboard” field of the bug or has announced they consider closing the bug and no further comments have been posted. Updates to important incidents (see e.g. https://www.ccadb.org/cas/public-group#lessons-learned-from-ca-incident-reports) should be posted to either the [https://groups.google.com/a/ccadb.org/g/public CCADB Public list] or the [https://groups.google.com/a/mozilla.org/g/dev-security-policy MDSP mailing list] and the Bugzilla bug. The bug will be closed when remediation is completed.<br />
<br />
= Examples of Good Practice =<br />
<br />
Here are some examples of good practice, where a CA did most or all of the things recommended above. Note that these incident reports conformed to an earlier version of the incident reporting template.<br />
<br />
== Let's Encrypt Unicode Normalization Compliance Incident ==<br />
<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/g6_zGA2exXw Initial Public Problem Report], 2017-08-10 20:23 UTC (apparently LE were made aware of the problem privately earlier that day)<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/g6_zGA2exXw/_tXldrbIBwAJ Initial Public Response from CA], 2017-08-10 21:53 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/nMxaxhYb_iY/AmjCI3_ZBwAJY Final Report from CA], 2017-08-11 03:00 UTC<br />
<br />
In this case, the CA managed to diagnose the problem, remediate it, and deploy the fix to production within 24 hours.<br />
<br />
== PKIOverheid Short Serial Number Incident ==<br />
<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ Initial Public Problem Report], 2017-07-18 22:26 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/TzH5eI9dAQAJ Initial Public Response from CA], 2017-07-25 19:20 UTC<br />
* [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ Final Report from CA], 2017-08-11 14:39 UTC<br />
<br />
While the CA could have provided interim updates, and the final report was a little delayed, the contents of it were excellent.<br />
<br />
== SecureTrust "Some-State" in stateOrProvinceName ==<br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374 Initial Public Problem Report], 2019-05-14 00:49 UTC<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374#c1 Initial Public Response from CA], 2017-05-15 19:40 UTC<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374#c8 Final Report from CA], 2017-06-14 9:43 UTC<br />
<br />
The level of detail provided by the CA in both the initial report and follow-up responses is comprehensive, as is the work performed to identify additional occurrences and to remediate the issue.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Responding_To_An_Incident&diff=1248615CA/Responding To An Incident2023-10-17T21:18:40Z<p>Bwilson: Updated incident reporting instructions</p>
<hr />
<div>This page discusses incidents, incident reporting, remediation, and communication. It gives guidance to CAs as to how Mozilla expects them to react to reported incidents such as misissuances, and what the best practices are. <br />
<br />
An incident arises any time a CA fails to comply with an applicable requirement found in the Mozilla Root Store Policy, the CA/Browser Forum's requirements, or the CCADB's requirements. As noted in section 2.4 of the Mozilla Root Store Policy, a compliance incident can arise from certificate misissuance, delayed revocation, procedural or operational issues, or some other cause. <br />
<br />
A "misissuance" is defined as any certificate issued in contravention of any applicable standard, process or document - so it could be RFC non-compliant, BR non-compliant, issued contrary to the CA's CP/CPS, or have some other flaw or problem. <br />
<br />
Much of the content that previously was here has been moved to '''https://www.ccadb.org/cas/incident-report'''.<br />
<br />
Researchers who report CA incidents such as misissuances are welcome to include a link to that page in their report to the CA, reminding the CA of Mozilla's expectations for incident reporting. Sometimes our guidance is framed in terms of misissuance of certificates; it will need to be adapted as necessary for incidents of a different nature, respecting the spirit of the information requests contained in the standard incident-reporting template.<br />
<br />
Other examples of incidents include misconfigured CRLs and OCSP responders, delayed responses, failures to properly communicate information, and any other event affecting trust in the WebPKI which does not involve the actual contents of certificates.<br />
<br />
While some forms of incident may be seen as less serious than others, opinions may vary. Mozilla sees all incidents as good opportunities for CA operators to confirm that their incident response processes are working well, and so we expect a similar level of timeliness of response and quality of reporting for all incidents, whatever their adjudged severity.<br />
<br />
To be clear, the [https://www.ccadb.org/cas/incident-report#incident-report-template incident report template] and incident-reporting process provide a set of best practices. Therefore, failure to follow one or more of the recommendations alone is not by itself sanctionable. However, failure to do so without good reason may affect Mozilla's general opinion of the CA. Our confidence in a CA is in part affected by the number and severity of incidents, but it is also significantly affected by the speed and quality of incident response. <br />
<br />
= Immediate Actions =<br />
<br />
In misissuance cases, a CA should almost always immediately cease issuance from the affected part of its PKI. In situations not involving misissuance, there also may be processes that need to be stopped until the CA has diagnosed the source of the problem.<br />
<br />
Once the problem is diagnosed, if the CA is able to put in place temporary or manual procedures to prevent the problem from re-occurring, it may restart the process even if a full fix is not rolled out. CAs should not restart affected processes until they are confident that the problem will not re-occur.<br />
<br />
= Revocation =<br />
<br />
It is normal practice for CAs to revoke misissued or otherwise problematic certificates. But that leaves the question about '''when''' this should be done, particularly if it's not possible to contact the customer immediately, or if they are unable to replace their certificate quickly. CAs should ensure that they are complying with Sections 4.9.1 through 4.9.5 of '''[https://cabforum.org/baseline-requirements-documents/ the CA/Browser Forum’s Baseline Requirements]'''. <br />
<br />
This means that, in most cases of misissuance, the CA has an obligation under the BRs to revoke the certificates concerned within 24 hours, or 5 days in some cases.<br />
<br />
Mozilla recognizes that in some '''exceptional''' circumstances, revoking the affected certificates within the prescribed deadline may cause significant harm, such as when the certificate is used in critical infrastructure and cannot be safely replaced prior to the revocation deadline, or when the volume of revocations in a short period of time would result in a large cumulative impact to the web. However, Mozilla does not grant exceptions to the BR revocation requirements. It is our position that your CA is ultimately responsible for deciding if the harm caused by following the requirements of the Baseline Requirements outweighs the risks that are passed on to individuals who rely on the web PKI by choosing not to meet this requirement.<br />
<br />
If your CA will not be revoking the certificates within the time period required by the BRs, our expectations are that:<br />
<br />
* A separate incident report will be filed in Bugzilla.<br />
* The decision and rationale for delaying revocation will be disclosed in the form of a preliminary incident report immediately; preferably before the BR-mandated revocation deadline. The rationale must include detailed and substantiated explanations for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.<br />
* Any decision to not comply with the timeline specified in the Baseline Requirements must also be accompanied by a clear timeline describing if and when the problematic certificates will be revoked or expire naturally, and supported by the rationale to delay revocation.<br />
* The issue will need to be listed as a finding in your CA’s next BR audit statement.<br />
* Your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable.<br />
* You will perform an analysis to determine the factors that prevented timely revocation of the certificates, and include a set of remediation actions in the final incident report that aim to prevent future revocation delays.<br />
<br />
If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.<br />
<br />
= Follow-Up Actions =<br />
<br />
* Work out how the bug or problem was introduced. For a code bug, were the code review processes sufficient? Does your code have automated tests, and if so, why did they not catch this case?<br />
<br />
* Work out why the problem was not detected earlier. Were these certificates missed by your linting processes or self audits? Or is the code or process you use for insufficient?<br />
<br />
* If the problem is lack of compliance to an RFC, Baseline Requirement, or Mozilla Policy requirement: were you aware of this requirement? If not, why not? If so, was an attempt made to meet it? If not, why not? If so, why was that attempt flawed? Do any processes need updating for making sure your CA complies with the latest version of the various requirements placed upon it?<br />
<br />
* Scan your corpus of certificates to look for others with the same issue. It does not look good for a CA to claim they have revoked all affected certificates and resolved the issue, and then for a researcher to discover another set of certificates with the same or a similar problem.<br />
<br />
* Examine whether there are potential related problems which you can also remediate at the same time. For example, if the problem was bad data in a particular field, consider improving the validation of all fields in the certificate prior to issuance. You should be proactively looking for ways, such as pre-issuance lint testing, to harden your issuance pipeline against further problems.<br />
<br />
* If, as happens in a regrettably large number of cases, a problem report was sent to your CA but action in accordance with BR section 9.4.5 was not taken within 24 hours, investigate what happened to that report and whether your report handling processes are adequate.<br />
<br />
= Incident Report =<br />
<br />
Your CA must submit an incident report by [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&version=other creating a bug in Bugzilla under the CA Program :: CA Certificate Compliance component]. When the incident is reported only on the CCADB public list or on the [https://groups.google.com/a/mozilla.org/g/dev-security-policy MDSP mailing list], then a bug will be created to track the incident and its resolution in Bugzilla. CAs are encouraged to announce important incidents on public@ccadb.org when they involve the Baseline Requirements, other root programs, or the CCADB; or on the Mozilla dev-security-policy list, when they only involve violations of the Mozilla Root Store Policy. <br />
<br />
The incident report should use the markdown template provided on the CCADB website:<br />
<br />
'''https://www.ccadb.org/cas/incident-report#incident-report-template''' <br />
<br />
= Keeping Us Informed =<br />
<br />
Once the report is posted, you should respond promptly to questions that are asked, and in no circumstances should a question linger without a response for more than one week, even if the response is only to acknowledge the question and provide a later date when an answer will be delivered. You should also provide updates at least every week giving your progress, and confirm when the remediation steps have been completed - unless a root store representative has agreed to a different schedule by setting a “Next Update” date in the “Whiteboard” field of the bug or has announced they consider closing the bug and no further comments have been posted. Updates to important incidents (see e.g. https://www.ccadb.org/cas/public-group#lessons-learned-from-ca-incident-reports) should be posted to either the [https://groups.google.com/a/ccadb.org/g/public CCADB Public list] or the [https://groups.google.com/a/mozilla.org/g/dev-security-policy MDSP mailing list] and the Bugzilla bug. The bug will be closed when remediation is completed.<br />
<br />
= Examples of Good Practice =<br />
<br />
Here are some examples of good practice, where a CA did most or all of the things recommended above. Note that these incident reports conformed to an earlier version of the incident reporting template.<br />
<br />
== Let's Encrypt Unicode Normalization Compliance Incident ==<br />
<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/g6_zGA2exXw Initial Public Problem Report], 2017-08-10 20:23 UTC (apparently LE were made aware of the problem privately earlier that day)<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/g6_zGA2exXw/_tXldrbIBwAJ Initial Public Response from CA], 2017-08-10 21:53 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/nMxaxhYb_iY/AmjCI3_ZBwAJY Final Report from CA], 2017-08-11 03:00 UTC<br />
<br />
In this case, the CA managed to diagnose the problem, remediate it, and deploy the fix to production within 24 hours.<br />
<br />
== PKIOverheid Short Serial Number Incident ==<br />
<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ Initial Public Problem Report], 2017-07-18 22:26 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/TzH5eI9dAQAJ Initial Public Response from CA], 2017-07-25 19:20 UTC<br />
* [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ Final Report from CA], 2017-08-11 14:39 UTC<br />
<br />
While the CA could have provided interim updates, and the final report was a little delayed, the contents of it were excellent.<br />
<br />
== SecureTrust "Some-State" in stateOrProvinceName ==<br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374 Initial Public Problem Report], 2019-05-14 00:49 UTC<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374#c1 Initial Public Response from CA], 2017-05-15 19:40 UTC<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551374#c8 Final Report from CA], 2017-06-14 9:43 UTC<br />
<br />
The level of detail provided by the CA in both the initial report and follow-up responses is comprehensive, as is the work performed to identify additional occurrences and to remediate the issue.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/CPS_Review&diff=1248582CA/CPS Review2023-10-13T15:16:09Z<p>Bwilson: Added link to review of Commscope's CP/CPS</p>
<hr />
<div><br />
Here are previous reviews of CP/CPS documents:<br />
<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9357960 Review of Commscope's CP/CPS (XLS)]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9342057 Review of TrustAsia's CP/CPS (XLS)]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9328642 Review of Sectigo's CPS (XLS)]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9328039 Review of Cybertrust Japan's CPS (XLS)]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9327554 Review of SSL.com's CP/CPS (XLS)]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9326434 Review of ATOS Trustcenter's CPS (XLS)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1647181#c24 Second Review of BJCA's CPS]<br />
* [https://bugzilla.mozilla.org/attachment.cgi?id=9284758 Review of Fina's CPS and Compliance Self Assessment (XLS)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1431811#c14 Review of Notarius' CPS (email-only)] <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1592138#c8 Review of Macao Post eSignTrust CPS (email-only)] <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1694421#c17 Review of DigitalSign's CPS (email-only)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1710831#c16 Review of LAWtrust's CPS (email-only)] <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1677631#c73 Comments to SERPRO's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1727941#c11 Review of Certainly's CP/CPS] [https://bugzilla.mozilla.org/attachment.cgi?id=9270636 (Download full review in XLS attachment)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1313982#c41 Review of SECOM's CPs and CPSes] <br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1628720#c19 Second review of eTugra's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1628720#c16 BR and EV Review on eTugra's CPS] [https://bugzilla.mozilla.org/attachment.cgi?id=9254979 (Download full review in XLS attachment)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1706228#c9 BR and EV Review on DigiCert's CP/CPS] [https://bugzilla.mozilla.org/attachment.cgi?id=9252944 (Download full review in XLS attachment)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1679258#c9 BR and EV Review on D-TRUST's CP/CPS] [https://bugzilla.mozilla.org/attachment.cgi?id=9243128 (Download full review in XLS attachment)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c50 Detailed Extended Validation Review Feedback to iTrusChina on EV aspects of CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1454977#c75 Second Review on ACIN - Global Trusted Sign's CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1664161#c6 Detailed BR Review Feedback to Telia on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1705904#c20 BR Review of KIR's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1454977#c52 Detailed BR and EV Review Feedback to ACIN - Global Trusted Sign]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1102143#c38 Detailed BR and EV Review Feedback on Firmaprofesional's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1563417#c19 Detailed BR and EV Review Feedback on Chunghwa Telecom's CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1695487#c6 Detailed BR Review Feedback to HARICA on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1701317#c6 Detailed Review Feedback to ISRG/Let's Encrypt on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1690054#c8 Detailed Extended Validation Review Feedback to HARICA on EV aspects of CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1493679#c25 Detailed BR and EV Review Feedback to Network Solutions on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1627552#c13 Detailed BR and EV Review Feedback to GLOBALTRUST2020 on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1647181#c7 Detailed BR and EV Review Feedback to Beijing CA on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1579454#c9 Detailed Extended Validation Review Feedback to NetLock on EV aspects of CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1587779#c12 Detailed Review Feedback to TunTrust on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1585951#c36 Detailed Review Feedback to ANF on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1558450#c17 Detailed Review Feedback to Digidentity on CP/CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c30 Detailed Review Feedback to iTrusChina on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29 Detailed Review Feedback to NAVER Group on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1563417#c7 Detailed Review Feedback to Chunghwa Telecom on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1532426#c31 Initial Review Feedback to SSLCOM Group on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1551703#c6 Detailed Review Feedback to Identrust on CPS]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1528369#c10 Detailed Review Feedback to SecureTrust]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1479040#c42 Detailed Review Feedback to Certisign]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ Detailed Review Feedback on Microsec]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1102143#c25 Detailed Review Feedback on Firmaprofesional]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c13 Detailed Review Feedback on certSIGN CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1474556#c16 Detailed Review Feedback on Dubai Government CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1448093#c56 Detailed Review Feedback on Microsoft CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1480510#c10 Detailed Review Feedback on Entrust CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1464306#c29 Detailed Review Feedback on Hongkong Post CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1442337#c37 Detailed Review Feedback on eMudhra CA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1309797#c72 Detailed Review feedback on SHECA]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1325532#c41 Detailed Review Feedback on Google Trust Services]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1390803#c14 Detailed Review Feedback on GlobalSign]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/36t-jbTQnTY/nwkFyzobAgAJ Review Feedback on WISeKey]<br />
** That was after [https://bugzilla.mozilla.org/show_bug.cgi?id=1403591#c17 blocking problems with the CP/CPS] were resolved.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/skev4gp_bY4/snIuP2JLAgAJ Review Feedback on Camerfirma]<br />
** CA may submit new root inclusion request for newly generated root that is fully compliant with Mozilla's Root Store Policy and the BRs.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/R2uG3wisU7s/ie_v7RHMBwAJ Review Feedback on TrustCor]<br />
** CP and CPS documents clear, well written, and they provided sufficient detail to assess the policies in place. <br />
* Review Feedback on Kamu SM (Government of Turkey)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/EtJpw8r7uGs/NmOfjdKIAwAJ CPS document clear and well written]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/vjXyml8Hy-E/bhxftrNkEAAJ New requirements for Domain Validation] -- all CAs must update their CP/CPS according to section 3.2.2.4 of [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf version 1.4.1 of the BRs].<br />
* Review Feedback on Guangdong Certificate Authority (GDCA)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/YVOKPfnSAQAJ English translations of documents MUST match the original document.]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/blMVMaHlAwAJ CA is responsible for providing accurate translation.]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/zZ5RHXCkpGM/dvx0DjswBgAJ Review Feedback on Amazon Trust Services' CP/CPS]<br />
** Amazon was commended for the clarity of their CP and CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/eHC0JDQwBgAJ Review Feedback on Japan GPKI's CP/CPS]<br />
** Japan GPKI's CP/CPS did not contain sufficient detail, so discussion put on hold pending updated CP/CPS.<br />
* A-Trust discussion [https://groups.google.com/d/msg/mozilla.dev.security.policy/Q1beEDFdzxg/6ZILykF0AgAJ put on hold pending translation of CP/CPS into English].<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/bGWV7_lwBAAJ Review Feedback on ComSign's CP/CPS]<br />
** ComSign's discussion was put on hold until the CP/CPS is updated to conform to either RFC 2527 or RFC 3647, as required by the Baseline Requirements. And be translated into English.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ Review Feedback on SSC's CP/CPS]<br />
** SSC's discussion was put on hold pending updated CP/CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/gKCqWRmBQ_8/A1eI_zsoAAAJ Review Feedback on ISRG's CP/CPS]<br />
** ISRG's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/z1rc7vUSlb0/wJkwv5x3AgAJ Review Feedback on DocuSign's CP/CPS]<br />
** DocuSign's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/dYoQcI0e1qA/ucp1cHfVAAAJ Review Feedback on HARICA's CP/CPS]<br />
** HARICA's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ Review Feedback on LuxTrust's CP/CPS]<br />
** The concerns raised regarding LuxTrust's CP/CPS resulted in the inclusion request being put on hold until the CP/CPS was updated.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/Xvmolz36PsEJ Review Feedback on Krajowa Izba Rozliczeniowa (KIR) CP/CPS]<br />
** KIR updated their CP/CPS according to the [https://groups.google.com/d/msg/mozilla.dev.security.policy/aNbK4zw_Zb8/wmwnbVbLb8cJ review feedback provided in their first discussion] <br />
** Then had to update their CP/CPS again due to feedback in their second discussion.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Compliance_Self-Assessment&diff=1248538CA/Compliance Self-Assessment2023-10-09T15:20:30Z<p>Bwilson: /* Compliance Self-Assessment - Root Inclusion or Update */ minor</p>
<hr />
<div>= Compliance Self-Assessment =<br />
<br />
CAs with root certificates that have the websites trust bit set are required to perform self-assessments at various times to ensure that their CP and CPS documents and their practices continue to comply with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] (BRs), [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy], and if applicable, the [https://cabforum.org/extended-validation/ EV Guidelines]. The preparation of this document reduces the load on the Mozilla administration team and makes it more likely the CA's request will be processed in a timely manner.<br />
<br />
== Template ==<br />
* The template for Compliance Self-Assessments is found here: https://www.ccadb.org/cas/self-assessment.<br />
<br />
== Compliance Self-Assessment - Annual ==<br />
<br />
CAs with included root certificates that have the websites trust bit set must do an annual self-assessment of their compliance with the BRs and Mozilla's Root Store Policy using the above template. When completed, the self-assessment should be uploaded to CA's Bugzilla bug that is used for storing the CA's audit documents, if one exists. Otherwise, a new bug can be created within the [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=CA+Documents "CA Documents" component of the CA Program] in Bugzilla.<br />
<br />
The BRs state: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements."<br />
<br />
CAs must update their CP and CPS documents at least once every year. You should indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the CP and CPS documents.<br />
<br />
== Compliance Self-Assessment - Root Inclusion or Update ==<br />
<br />
Mozilla's [[CA/Application_Process|root inclusion/update process]] has a [[CA/Application_Verification#Public_discussion|Public Discussion]] phase in which members of the community thoroughly review and discuss each CA's request. <br />
<br />
Mozilla requires CAs to perform a side-by-side comparison of their CP and CPS documents to the BRs and Mozilla's Root Store Policy (and EV Guidelines, if applicable) using the above template. Compliance Self-Assessments can either be attached to their Bugzilla bug or uploaded to another location where they can be easily obtained. During the public discussion in the [https://groups.google.com/a/ccadb.org/g/public CCADB Public list], members of the community will use the CA's self-assessment document to perform their own review, confirm the accuracy of the CA's self-assessment, ask questions, raise concerns, etc.</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA&diff=1248533CA2023-10-08T22:49:36Z<p>Bwilson: /* Information for CAs */ Added PKI Lint</p>
<hr />
<div>__NOTOC__<br />
= Mozilla's CA Certificate Program =<br />
<br />
Mozilla’s CA Certificate Program governs inclusion of root [https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates certificates] in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS Network Security Services (NSS),] a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of products. The program is overseen by the module owner and peers of the [[Modules/Activities#CA_Certificates|CA Certificates Module]]; the policy itself is overseen by the module owner and peers of the [[Modules/Activities#Mozilla_CA_Certificate_Policy|CA Certificate Policy Module]].<br />
<br />
== Policy ==<br />
<br />
* [https://www.mozilla.org/projects/security/certs/policy/ Root Store Policy] (current stable version: 2.9)<br />
* [[CA/Communications | CA Communications]] and their responses. Such communications may also set policy in advance of it being included in the Root Store Policy.<br />
* [[CA/Root_Store_Policy_Archive|Root Store Policy Archive]]<br />
* [[CA/Updating_Root_Store_Policy|Process for updating the Root Store Policy]]<br />
** [https://github.com/mozilla/pkipolicy/issues Root Store Policy Issue Tracker]<br />
** [https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md Latest draft of Root Store Policy] (will become the next version)<br />
* [[CA/Transition_SMIME_BRs|Transition to S/MIME BRs]]<br />
<br />
== Lists of CAs and Certificates ==<br />
* [https://www.ccadb.org/rootstores/usage#ccadb-data-usage-terms Data Usage Terms]<br />
* [[CA/Included_CAs|Included CAs]] (in the Root Program and in Firefox)<br />
* [[CA/Included_Certificates|Included CA Certificates]]<br />
* [[CA/Intermediate_Certificates|Intermediate Certificates]]<br />
* [[CA/Removed_Certificates|Removed CA Certificates]]<br />
* [[NSS:Release_Versions|NSS Release Versions]] - shows in which version of Mozilla products each root certificate was first available<br />
* [[CA/Additional_Trust_Changes| Additional Trust Policies ]] - describes trust policies enforced by PSM in Firefox and Thunderbird, but not represented in the NSS root store.<br />
<br />
== Program Administration ==<br />
<br />
Most information relating to the administration of our program is stored either in [https://bugzilla.mozilla.org/ Bugzilla] or in the [https://ccadb.org/ Common CA Database].<br />
<br />
* [[CA/Dashboard|Certificate Change Request Dashboard]] - tracks applications and trust changes through the process in Bugzilla<br />
** [[CA/Prioritization|Certificate Change Prioritization]] <br />
* [[CA/Certificate_Change_Requests|Certificate Change Requests]] as tracked in the CCADB<br />
* [[CA/Incident_Dashboard|Incident and Compliance Dashboard]]<br />
* [[CA/CCADB_Dashboard|CCADB Dashboard]]<br />
* [[CA/Bug_Triage|Bugzilla Bug Triage Process]]<br />
* [[CA/Email_templates|Email Templates used by CCADB]]<br />
<br />
====crt.sh====<br />
<br />
* [https://crt.sh/mozilla-disclosures Disclosure status of all certificates known to CT]<br />
* [https://crt.sh/?cablint=issues Problematic certificates issued in the past week known to CT]<br />
<br />
== Information for CAs ==<br />
* [https://ccadb.org/cas/ CCADB Login]<br />
* [[CA/Audit_Statements|Audit_Statements]]<br />
* [[CA/Responding_To_An_Incident|Responding to an Incident]] (such as a misissuance)<br />
* [[CA/Vulnerability_Disclosure|Disclosing a Vulnerability or Security Incident]]<br />
* [[CA/Application_Process|Application Process for Mozilla's Root Program]]<br />
** [[CA/Quantifying_Value|Quantifying Value: Information Expected of New Applicants]]<br />
** [[CA/Compliance_Self-Assessment|Compliance Self Assessment]]<br />
*** [[CA/CPS_Review|Previous reviews of CP/CPS documents]]<br />
** [[CA/Information_Checklist|CA Information Checklist]]<br />
** [[CA/Subordinate_CA_Checklist|Subordinate CA Information Checklist]]<br />
* [[CA/External_Sub_CAs|Approval Process for Externally Operated Subordinate CAs]] <br />
* [[CA/Certificate_Change_Process|Change or Remove an Included Root Certificate]]<br />
* [[CA/Root_CA_Lifecycles|Root CA Lifecycles]]<br />
* [[CA/Required_or_Recommended_Practices|Required or Recommended CA Practices]]<br />
* [[CA/Root_Inclusion_Considerations|Root Inclusion Considerations]] -- This page is intended to be used as a tool for identifying when a CA Operator's root inclusion request should be denied, or when a CA's root certificate should be removed from Mozilla's root store. <br />
** [[CA/Forbidden_or_Problematic_Practices|Forbidden or Problematic CA Practices]]<br />
** [[CA/Maintenance_and_Enforcement|Maintenance and Enforcement]]<br />
* [[SecurityEngineering/Certificate_Verification|How Firefox Performs Certificate Verification]] and path construction <br />
* [[CA/EV_Processing_for_CAs | How Firefox Processes EV Certificates]]<br />
* Revocation<br />
** [[CA/Revocation_Checking_in_Firefox|How Firefox Performs Revocation Checking]]<br />
** [[CA/Revocation_Reasons|Revocation Reasons for TLS Server Certificates]]<br />
* [[PSM:EV_Testing_Easy_Version|EV Readiness Test]]<br />
<br />
* [https://github.com/digicert/pkilint PKI Lint Tool for TLS & S/MIME] - source code download<br />
* [https://github.com/certlint/certlint BR Lint Certificate Test] - source code download<br />
* [https://github.com/zmap/zlint ZLint - Certificate Test of Mozilla's and others' requirements] - source code download<br />
* [https://github.com/kroeckx/x509lint X.509 Lint Certificate Test] - source code download<br />
* [[CA:TestErrors|Common Test Errors]]<br />
<br />
== Information for Auditors ==<br />
* [[CA/Audit_Statements#Auditor_Qualifications|Auditor Qualifications]]<br />
* [[CA/Auditor_Compliance|Auditor Compliance Dashboard]]<br />
* [[CA/BR_Audit_Guidance|Guidance on doing Baseline Requirements audits]]<br />
* [[CA/Auditor_Mistakes|Mistakes we have seen auditors make]] and their consequences<br />
<br />
== Information for the Public ==<br />
* [https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/ Why Does Mozilla Maintain Our Own Root Certificate Store?]<br />
* [https://blog.mozilla.org/security/2019/04/15/common-ca-database-ccadb/ What is the Common CA Database (CCADB)?]<br />
* [[CA/FAQ|FAQ About Certificates and CAs]]<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/ProblemReportingMechanismsReport List of CA problem reporting mechanisms (email, etc.)] (use this to report a certificate problem directly to the CA)<br />
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance Report an Incident to Mozilla] (be sure to click the "Security" checkbox if it is a [https://www.mozilla.org/en-US/security/#For_Developers security-sensitive incident])<br />
* [[CA/Terminology|Glossary of CA and Certificate Terminology]]<br />
* [[CA/Changing_Trust_Settings|Changing Certificate Trust Settings in Firefox]]<br />
** [[CA/Changing_Trust_Settings#Trusting_an_Additional_Root_Certificate|Manually import a root certificate into Firefox]]<br />
* [https://tls-observatory.services.mozilla.com/static/certsplainer.html Mozilla's Certificate Explainer]<br />
* [https://www.ssllabs.com/ssltest/analyze.html Qualys SSL Server Quality Checker]<br />
* [https://observatory.mozilla.org/ Mozilla SSL Server Quality Checker]<br />
* [[CA/Revocation_Checking_in_Firefox|How Firefox performs revocation checking]]<br />
* [https://certificate.revocationcheck.com/ Certificate Revocation Checker] (also checks CRL and OCSP server quality and compliance)<br />
* [https://ccadb.my.salesforce-sites.com/mozilla/CAAIdentifiersReport List of CAA Identifiers] (used to restrict issuance of certificates to specific CAs via a [https://tools.ietf.org/html/rfc6844 DNS Certification Authority Authorization Resource Record])<br />
* [[CA/AddRootToFirefox|How to install your own root certificate in Firefox]]<br />
<br />
== Discussion Forums ==<br />
<br />
The following public forums are relevant to CA evaluation and related issues. <br />
<br />
===== CCADB =====<br />
* '''[https://groups.google.com/a/ccadb.org/g/public CCADB Public mailing list''' is used to conduct a six-week public discussion of CA root inclusion requests and to discuss important lessons learned from CA incident reports. See https://www.ccadb.org/cas/public-group for more information.<br />
<br />
===== MDSP =====<br />
* '''[https://groups.google.com/a/mozilla.org/g/dev-security-policy Mozilla's dev-security-policy (MDSP)] mailing list''' is used for discussions of Mozilla policies related to security in general and CAs in particular, and for wider discussions about the WebPKI. If you are a regular participant in MDSP, then please add your name to the [[CA/Policy_Participants|Policy Participants]] page.<br />
<br />
===== Other MDSP Mail Archives =====<br />
* '''New MDSP Messages''' (since August 2021)<br />
<br />
(HTML): https://www.mail-archive.com/dev-security-policy@mozilla.org/<br />
<br />
(RSS): https://www.mail-archive.com/dev-security-policy@mozilla.org/maillist.xml<br />
<br />
* '''Old MDSP Messages''' (until April 2021)<br />
<br />
(HTML): https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/<br />
<br />
(RSS): https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/maillist.xml<br />
<br />
===== Other Forums =====<br />
* [https://groups.google.com/a/mozilla.org/g/dev-tech-crypto Mozilla's dev-tech-crypto] mailing list is used for discussions of the [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] cryptographic library used in Firefox and other Mozilla-based products, as well as the [https://www.mozilla.org/projects/security/pki/psm/ PSM] module that implements higher-level security protocols for Firefox.<br />
* For other discussions of Mozilla security issues:<br />
** [https://discourse.mozilla.org/c/security/ Mozilla's Security Web forum] is a place to discuss information security work in the open source space, where Mozilla is empowering users to build and curate a Healthy Internet.<br />
** [https://discourse.mozilla.org/tags/c/firefox-development/privacy-and-security Mozilla's privacy-and-security forum] is a place to discuss issues and questions specific to privacy and security.<br />
** [https://chat.mozilla.org/#/room/#security:mozilla.org chat on Matrix] may also be used</div>Bwilsonhttps://wiki.mozilla.org/index.php?title=CA/Compliance_Self-Assessment&diff=1248190CA/Compliance Self-Assessment2023-09-28T15:50:51Z<p>Bwilson: /* Compliance Self-Assessment - Root Inclusion or Update */ Referenced other locations for upload of self-assessment</p>
<hr />
<div>= Compliance Self-Assessment =<br />
<br />
CAs with root certificates that have the websites trust bit set are required to perform self-assessments at various times to ensure that their CP and CPS documents and their practices continue to comply with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] (BRs), [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy], and if applicable, the [https://cabforum.org/extended-validation/ EV Guidelines]. The preparation of this document reduces the load on the Mozilla administration team and makes it more likely the CA's request will be processed in a timely manner.<br />
<br />
== Template ==<br />
* The template for Compliance Self-Assessments is found here: https://www.ccadb.org/cas/self-assessment.<br />
<br />
== Compliance Self-Assessment - Annual ==<br />
<br />
CAs with included root certificates that have the websites trust bit set must do an annual self-assessment of their compliance with the BRs and Mozilla's Root Store Policy using the above template. When completed, the self-assessment should be uploaded to CA's Bugzilla bug that is used for storing the CA's audit documents, if one exists. Otherwise, a new bug can be created within the [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA+Program&component=CA+Documents "CA Documents" component of the CA Program] in Bugzilla.<br />
<br />
The BRs state: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements."<br />
<br />
CAs must update their CP and CPS documents at least once every year. You should indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the CP and CPS documents.<br />
<br />
== Compliance Self-Assessment - Root Inclusion or Update ==<br />
<br />
Mozilla's [[CA/Application_Process|root inclusion/update process]] has a [[CA/Application_Verification#Public_discussion|Public Discussion]] phase in which members of the community thoroughly review and discuss each CA's request. <br />
<br />
Mozilla requires CAs to perform a side-by-side comparison of their CP and CPS documents to the BRs and Mozilla's Root Store Policy (and EV Guidelines, if applicable) using the above template. The Compliance Self-Assessment can either be attached to their Bugzilla bug or uploaded to another location where they can be easily obtained. During the public discussion in the [https://groups.google.com/a/ccadb.org/g/public CCADB Public list], members of the community will use the CA's self-assessment document to perform their own review, confirm the accuracy of the CA's self-assessment, ask questions, raise concerns, etc.</div>Bwilson