> https://wiki.mozilla.org/CA:Root_Change_Process

> https://wiki.mozilla.org/CA:Root_Change_Process

> This page is linked to from https://wiki.mozilla.org/CA:Overview in the
> "Work in progress" section. The link is called "Root Change Process".

> In writing this process, I have taken into account input that was
> provided through previous discussions, bug postings, the previous
> removal policy notes
> (https://wiki.mozilla.org/CA:Root_Removal_Policy_Notes), and my current
> work to clean up the legacy roots that are no longer audited/used.

> I will greatly appreciate your feedback on the new documentation for the
> root change process: https://wiki.mozilla.org/CA:Root_Change_Process

> Kathleen

> Under "Disable a Root", the second subbullet under the first bullet of
> #3 is not worded in parallel with the first subbullet.  It looks
> strange.  Perhaps, it should be "Whether the root certificate should be
> removed from NSS instead of unsetting trust bits."  (In the first
> subbullet, "trust bits" should not be capitalized.)

> Under "Disable a Root", the fourth bullet under #3 is not clear.  Where
> it says " ... a qualified representative of either the CA or Mozilla has
>   ... ", is the qualified representative of Mozilla distinct from the
> Mozilla representative cited at the beginning of the sentence?  I think
> it should be; that is, it should take at least two senior Mozilla staff
> memeber to disable a root if the CA is not in agreement.

> In #4-6 under "Disable a Root" (referring back to my comment immediately
> above), to which representative of Mozilla do these refer?

>> In #7 under "Disable a Root", are you able to unset a trust bit in a
>> root certificate that is already installed in a Mozilla-based product on
>> my PC?

> Yes.
> Preferences -> Advanced -> Encryption -> View Certificates -> Edit...

>> That raises the question under "Add a Trust Bit":  Are you able
>> to set a trust bit in a root certificate that is already installed in a
>> Mozilla-based product on my PC?

> Yes.
> Preferences -> Advanced -> Encryption -> View Certificates -> Edit...

> Your own settings of trust bits will always over-ride the default
> settings.  If you have already changed the trust bits, then updating to
> a new version of FireFox will not change your settings, even if the
> default settings have been changed.

> The main affect of removing a root from NSS is for the default set of
> roots.

> When I have added roots before they're included in NSS they do seem to
> get converted to BuiltIn Object Tokens when NSS does include them.
> However, my trust bit settings remain.

> If I have added a root that is not included in NSS, it doesn't get
> changed in any way when I update versions of Firefox as long as the root
> is not included in Firefox.

> I knew how I can change trust bits.  I've done it before on reports of
> careless operations of various certificate authorities.

> I want to know how you -- Mozilla -- can change the trust bits on my PC.
>  That's effectively the following question.

> 1.  I update SeaMonkey on my PC, which contains a new NSS database.  In
> that database, a root certificate that previously was present is now
> removed.  As a result of updating SeaMonkey on my PC, the root
> certificate is removed from my PC's configuration.

>> https://wiki.mozilla.org/CA:Root_Change_Process

>> This page is linked to from https://wiki.mozilla.org/CA:Overview in the
>> "Work in progress" section. The link is called "Root Change Process".

>> In writing this process, I have taken into account input that was
>> provided through previous discussions, bug postings, the previous
>> removal policy notes
>> (https://wiki.mozilla.org/CA:Root_Removal_Policy_Notes), and my current
>> work to clean up the legacy roots that are no longer audited/used.

>> I will greatly appreciate your feedback on the new documentation for the
>> root change process: https://wiki.mozilla.org/CA:Root_Change_Process

>> Kathleen

> Much of this Wiki reads like a policy and not merely a procedure.  After
> an extended public discussion, I think this should be subjected to
> formal approval by the Mozilla organization, moved out of
> wiki.mozilla.org, and made into a Web page at
> http://www.mozilla.org/projects/security/certs.

> Under "Add a Trust Bit", the first two bullets under #4 currently read
> as if an existing bug report is being updated.  However, #4 is clearly
> about a new bug.  In the first bullet, "Change the bug summary ... "
> should instead be "Set the bug summary ... ".  In the second bullet, "In
> the bug description add a reference ... " should instead be "In the bug
> description, include a reference ... ".  (Note the added comma.)  This
> same comment applies to #4 under "Enable EV".

> Under "Disable a Root", #1 does not indicate a need for the affected CA
> to submit the bug report.  Instead, this section implies that anyone can
> submit it.  This is different from "Add a Trust Bit" and "Enable EV",
> both of which state in their lead sentences that the affected CA submits
> the bug report.  If this difference is intentional, there should be no
> implication; an explicit statement is needed.  For example, #1 could
> read: "Any individual may initiate the request."

> Under "Disable a Root", the second subbullet under the first bullet of
> #3 is not worded in parallel with the first subbullet.  It looks
> strange.  Perhaps, it should be "Whether the root certificate should be
> removed from NSS instead of unsetting trust bits."  (In the first
> subbullet, "trust bits" should not be capitalized.)

> Under "Disable a Root", the fourth bullet under #3 is not clear.  Where
> it says " ... a qualified representative of either the CA or Mozilla has
>  ... ", is the qualified representative of Mozilla distinct from the
> Mozilla representative cited at the beginning of the sentence?  I think
> it should be; that is, it should take at least two senior Mozilla staff
> memeber to disable a root if the CA is not in agreement.

> In #4-6 under "Disable a Root" (referring back to my comment immediately
> above), to which representative of Mozilla do these refer?

> In #7 under "Disable a Root", are you able to unset a trust bit in a
> root certificate that is already installed in a Mozilla-based product on
> my PC?  That raises the question under "Add a Trust Bit":  Are you able
> to set a trust bit in a root certificate that is already installed in a
> Mozilla-based product on my PC?  What if I have already changed a trust
> bit in my own configuration to a value different from the way it is in
> the controlled NSS database?

> Under "Disable a Root", the same comments for "Disable a Root" also
> apply.  Regarding the comment about unsetting and setting trust bits for
> "Disable a Root", I question whether you are able to remove a root
> certificate from my own PC's configuration.  What if I have added a root
> certificate that is not in the controlled NSS database?  If you do
> indeed remove a root certificate from my PC and I then add it back into
> my configuration, can you later remove it again?

> Under both "Disable a Root" and "Disable a Root", the process described
> in the Wiki will take too long if there is a serious security
> vulnerability resulting from the presence of a certificate root in the
> NSS database or the setting of a particular trust bit in that
> certificate.  Both of these sections require some provision for
> "shortcutting" the process in that case, possibly skipping step #5 and
> placing step #8 ahead of step #7.

>> One additional comment:

>> Under both "Disable a Root" and "Disable a Root", the process described
>> in the Wiki will take too long if there is a serious security
>> vulnerability resulting from the presence of a certificate root in the
>> NSS database or the setting of a particular trust bit in that
>> certificate.  Both of these sections require some provision for
>> "shortcutting" the process in that case, possibly skipping step #5 and
>> placing step #8 ahead of step #7.

> There is a section called "Security Compromise" at the top of the page.
> This section says: "When a serious security concern is noticed, such as
> a major root compromise, it should be treated as a security-sensitive
> bug, and the Mozilla Policy for Handling Security Bugs should be followed."

> In the "Remove a Root" section the first reason is "Security
> Compromise", and it has a sub-bullet that says:
> "Root removals that are motivated by a serious security concern such as
> a major root compromise should be treated as a security-sensitive bug,
> and the Mozilla Policy for Handling Security Bugs should be followed."

> Also in both of the "Disable a Root" and "Remove a Root" sections,
> process step #4 says:
> "The Mozilla representative will deliver any preliminary decisions
> * It may be necessary to treat the bug as a sensitive security issue and
> follow the Mozilla Policy for Handling Security Bugs"

> In the "Disable a Root" section I just added the following under the
> reasons list, but before the process description:
> "Important: Root changes that are motivated by a serious security
> concern such as a major root compromise should be treated as a
> security-sensitive bug, and the Mozilla Policy for Handling Security
> Bugs should be followed."

> In each of these, "Mozilla Policy for Handling Security Bugs" links to:
> http://www.mozilla.org/projects/security/security-bugs-policy.html

> Is that sufficient clarification?

> I don't want to call the "Mozilla Policy for Handling Security Bugs" the
> "shortcutting" process. But it is the process that should be followed if
> it is determined that there is a serious security vulnerability.

> Thanks,
> Kathleen

> For simplicity, I will assume the basic and most common configuration, in
> which you have only the software distributed by Mozilla and do not have any
> additional PKCS#11 modules (with or without any additional hardware)
> installed that may be capable of storing additional certificates.  The
> model with them is slightly more complicated than the one I'm about to
> present, but only slightly.

> NSS is capable of accessing certificates that have been stored in a number
> of places, all accessible through the PKCS#11 API.  The two places of
> greatest interest are

> #1) Your certificate database, which is kept in a file on disk that you can
> alter.  It starts out empty.  Any root certificates it contains are there
> because of actions that you have taken, such as downloading or importing
> roots, or editing trust flags.  As a rule, an update to your Mozilla
> installation of a Mozilla product will not change the contents
> of this database.  (Rarely, it may change the FORMAT of the database, but
> not the content.)

> #2) Mozilla's trusted root list, kept in a read-only shared library which
> is one of the files that gets updated whenever your product's executable
> files get updated.

> Both of these stores of certificates may contain certificates and trust
> flags.

> When NSS goes looking for a stored certificate, or trust flags for a stored
> certificate, it first looks in your certificate database.  If it finds the
> certificate there, it stops.  It uses whatever trust flags are there in
> that database with that certificate.

> If it does NOT find the certificate it wants in that database, it looks in
> Mozilla's trusted root list.  If it finds the cert there, then it uses the
> cert and trust flags it finds there.  It does not copy the cert and flags
> from the root list into your database.  It just uses them where and as they
> are.

> When you use your product's certificate manager to edit the trust flags on
> a certificate, the cert manager first looks for the cert in your database,
> and if it's there, then that copy gets edited.  If it's not there, then
> cert manager looks for a copy in the trusted cert list, and if found,
> copies it and its flags into your data base, and then edits it there.
> (After all, it cannot edit the copy in Mozilla's list, because that copy
> is read-only.)  After that, that cert will remain in your database, and
> each time that the product goes looking for it, it will find it in your
> database, not in the trusted list.

> If you delete a cert in your database, one that is also in the trusted
> list, it may appear to be completely gone, until you restart your program,
> at which point it will reappear, because it never left the trusted root
> list.  It may reappear in the trusted root list with the trust flags from
> that list.  That's why we tell people that if they want to get rid of a
> root, the thing to do is NOT to delete it, but rather is to take away all
> its trust.  (The behavior when a cert is deleted has changed a few times
> over the years.)

> If you edit the trust on a cert in the root list, taking away (say) one of
> the 3 trust flags, but leaving the other two, then that cert and the two
> trust bits will be in your cert DB.  After that, if Mozilla removes that
> cert completely from Mozilla's trust list, it will remain in your cert DB
> with those two trust flags.  Mozilla's changes to the default trust list
> never affect your databases.  Your databases contain what YOU put there.
> They're your baby, your responsibility.

> In conclusion, the changes Mozilla makes to Mozilla's read-only list of
> trusted root certs affect only those certs that do not also appear in your
> cert DB.  When you cause copies of any of those certs to appear in your
> cert DB, then you have taken control of the trust for those copies, and
> changes made by Mozilla thereafter to those certs will not affect you.

> 1.  If I change one trust bit for a root certificate, that certificate
> then is copied to my personal cert DB before the trust bit is actually
> changed.  If an update to SeaMonkey includes a change in trust bits to
> that same certificate in the read-only cert DB, the fact that the
> certificate now also resides in my personal cert DB causes the
> certificate to be used with my trust bit settings, not with the
> read-only DB trust bit settings.  My concern here is that I should be
> informed when the read-only cert DB is updated that there is an
> inconsistency in the trust bits between that DB and my personal cert DB.

> 2.  Similarly, again if I change one trust bit for a root certificate,
> that certificate then is copied to my personal cert DB before the trust
> bit is actually changed.  If an update to SeaMonkey includes a deletion
> of that root certificate from the read-only cert DB, the copy in my
> personal cert DB remains and will still be used.  My concern here is
> that I should be informed when the read-only cert DB is updated that a
> cert remaining in my personal cert DB has been deleted from the
> read-only cert DB.

>> However, I'm left with two concerns:

>> 1.  If I change one trust bit for a root certificate, that certificate
>> then is copied to my personal cert DB before the trust bit is actually
>> changed.  If an update to SeaMonkey includes a change in trust bits to
>> that same certificate in the read-only cert DB, the fact that the
>> certificate now also resides in my personal cert DB causes the
>> certificate to be used with my trust bit settings, not with the
>> read-only DB trust bit settings.  My concern here is that I should be
>> informed when the read-only cert DB is updated that there is an
>> inconsistency in the trust bits between that DB and my personal cert DB.

>> 2.  Similarly, again if I change one trust bit for a root certificate,
>> that certificate then is copied to my personal cert DB before the trust
>> bit is actually changed.  If an update to SeaMonkey includes a deletion
>> of that root certificate from the read-only cert DB, the copy in my
>> personal cert DB remains and will still be used.  My concern here is
>> that I should be informed when the read-only cert DB is updated that a
>> cert remaining in my personal cert DB has been deleted from the
>> read-only cert DB.

> It sounds like we may want to request an enhancement that when a new
> version of NSS is installed the user receive a notification when root
> certificate trust bit settings in their personal cert DB differ from the
> root certificate trust bit settings in the default root store.

> Correct?

> However...

> I am under the impression that most users don't change the settings of
> root certificate authorities unless they need to add a root.

> I am concerned that warning users of differences between their personal
> cert DB and the default cert DB could cause a lot of confusion for the
> majority of users.

> Kathleen