New wiki page called CA:Root_Change_Process
Kathleen Wilson
root certificate that is currently included in NSS. This includes the
process for disabling or removing a root certificate from NSS.
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
Eddy Nigg
> I have created a new wiki page which outlines the process for changing
> a root certificate that is currently included in NSS. This includes
> the process for disabling or removing a root certificate from NSS.
>
> https://wiki.mozilla.org/CA:Root_Change_Process
>
Impressive! I haven't had the time to review into depth, but it appears
to be quite complete (by browsing through it).
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
David E. Ross
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 "Remove 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?
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. � 1997
Kathleen Wilson
>> https://wiki.mozilla.org/CA:Root_Change_Process
> 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.
Yes, at some point some parts of this belong in the policy, probably in
the Mozilla CA Policy. Similar to inclusion requests, there will be the
need for both the policy and for the process description.
Let's start with the information combined into this wiki page for now,
and put it to actual use.
> 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".
Updated in both sections.
> 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?
>
Updated in the "Disable a Root" section. I'll update the "Remove a
Root" section tomorrow.
> 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...
> 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?
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.
> Under "Remove 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?
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.
Thanks for your input!
Kathleen
David E. Ross
>
>> 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...
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.
>> 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?
>
> 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.
How do you distinguish between default NSS settings and my over-ride
settings? When I update (in my case) SeaMonkey and there is a change
for trust bit settings in the NSS database in the update, how do I avoid
having my over-rides ignored? That is, is the update handled to
preserve my over-rides even when the conflict with CHANGED NSS defaults?
On the other hand, if my over-rides are indeed preserved, perhaps I
should get some kind of warning during the update. After all, the
change in the NSS default trust bits might have been prompted by a
serious security failure.
>> Under "Remove 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?
>
> 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.
Consider the following sequence of events:
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.
2. I locate the removed certificate, download it, and use SeaMonkey to
reinstall it in my PC's configuration.
3. I get a later SeaMonkey update for my PC. It too contains a new NSS
database.
What happens when I install that later SeaMonkey update? Does the
previously removed and reinstalled root certificate get removed again?
Does it remain?
What happens if I DO NOT install the first SeaMonkey update and thus do
not have to download and reinstall the root certificate but then do
install the second update? Is the root certificate removed at that time?
In any case, do I get any kind of warning that a root certificate is
being (or should be) removed while updating SeaMonkey?
aero...@gmail.com
On Tue, Feb 2, 2010 at 5:47 PM, David E. Ross <nob...@nowhere.invalid> wrote:
>
> 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.
They do it by changing libnssckbi.so, libnssckbi.dylib, or nssckbi.dll.
> How do you distinguish between default NSS settings and my over-ride
> settings? When I update (in my case) SeaMonkey and there is a change
> for trust bit settings in the NSS database in the update, how do I avoid
> having my over-rides ignored? That is, is the update handled to
> preserve my over-rides even when the conflict with CHANGED NSS defaults?
The presence of a trust setting for a given root in the user's profile certificate store overrides what's in libnssckbi.
> On the other hand, if my over-rides are indeed preserved, perhaps I
> should get some kind of warning during the update. After all, the
> change in the NSS default trust bits might have been prompted by a
> serious security failure.
I agree.
> Consider the following sequence of events:
>
> 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.
If you have certificates issued under that root, usually you have the root and the intermediate certs in your store as well, and thus completely moot this issue. In the event that you don't, though...
> 2. I locate the removed certificate, download it, and use SeaMonkey to
> reinstall it in my PC's configuration.
At this point you're not adding the root to the NSS database (nssckbi, the one distributed by Mozilla), you're adding it to your own user profile's security store. Along with its desired trust settings. The user profile security token *always* takes precedence over nssckbi.
> 3. I get a later SeaMonkey update for my PC. It too contains a new NSS
> database.
It gets a new nssckbi.
> What happens when I install that later SeaMonkey update? Does the
> previously removed and reinstalled root certificate get removed again?
> Does it remain?
It remains in your user profile, where the trust settings you set on it are also preserved. The one in the new nssckbi (and its default trust bits) is completely ignored.
> What happens if I DO NOT install the first SeaMonkey update and thus do
> not have to download and reinstall the root certificate but then do
> install the second update? Is the root certificate removed at that time?
If the second update is the one that contains the nssckbi including that root, then that root would be available even if you haven't explicitly added it to your user profile store.
> In any case, do I get any kind of warning that a root certificate is
> being (or should be) removed while updating SeaMonkey?
Nope. That's part of the "Release Notes".
-Kyle H
(who, I hope it's obvious, speaks only for himself)
David E. Ross
> 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?
>
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.
Kathleen Wilson
> 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
David E. Ross
Aha! I was looking at the trees, not at the forest. Yes, what is in
the Wiki is sufficient regarding accelerating the process for a serious
security vulnerability.
Nelson B
answering any one of them, by trying to give you a simple explanation of
how this all works, a simple model that you can carry in your head, with
which you should find all Mozilla products' behaviors to be consistent.
When you understand this model, you should find that you are able to answer
your own questions intuitively from your own understanding of this model.
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.
David E. Ross
I really appreciate your description of what happens. It removes some
of my concerns.
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.
Kathleen Wilson
> 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
David E. Ross
Yes, you are correct. I'm going to think this over and then submit an
RFE bug report.
Your last concern is questionable. Anyone who has altered the trust
bits on existing root certificates in the read-only NSS database or who
has installed a root certificate in their personal database that is not
in the NSS read-only database should be able to understand completely a
warning about inconsistency between the two databases.
What I must consider is when the warning would appear. Should it
interrupt an installation of a browser? Should it appear only the first
time the databases are queried for any certificate? Or should it appear
whenever a certificate with a conflict is used?