Closed Bug 152397 Opened 22 years ago Closed 15 years ago

Cannot edit Root CAs with FIPS enabled

Categories

(Core Graveyard :: Security: UI, defect)

1.0 Branch
x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: junruh, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [kerh-coz])

1.) With a new profile, enable FIPS.
2.) Open Cert Manager, and click on Authorities tab.
3.) Edit a CA and click OK.
What happens: I cannot click OK.
Blocks: fips
Keywords: nsbeta1
That's another side effect of our incorrect behaviour to allow FIPS mode without
having a master password set.
Depends on: 106587
I suggest to resolve this as wontfix.

While this problem continues to happen with existing profiles, having FIPS
already enabled, those profiles aren't really usable anyway, until the user
manually fixes it.

Now that bug 106587 has been fixed, we'll prevent creating such profiles in the
future.


John, if you think this problem is unrelated to not having a master password in
FIPS mode, please reopen.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
V
Status: RESOLVED → VERIFIED
Reopening. This still occurs if you have FIPS enabled, but have not logged in 
to the DB yet. This also occurs with web site certs.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Ok, confirming, we still have this problem.
I think we should find a different approach to this.

It appears, in FIPS mode, you can not do any crypto operations without being
logged on to the token.

It seems that Mozilla is not paying attention to that. Instead, it seems Mozilla
just assumes the standard non-FIPS mode, and only has code to request the user
log in, if it is actually require in non-FIPS mode.

I see two solutions to this problem:

1.)
Try to track down all code locations, where
- being logged in is not required in non-FIPS mode
- being logged in is required in FIPS mode
- we currently do not have logic to ensure the user is logged in if FIPS mode is
active
- add a check for FIPS mode and the not logged in state to all those locations

2.)
At the time we initialize the security database during a session, detect whether
we are in FIPS mode, and if we are, require the user to log in right away.


On first sight, it looks like 2) is a much simpler solution and sufficient.

However, I realize there is still the functionality to "log out" of the token. I
guess we probably need to support that, even when in FIPS mode.

Do you agree that we indeed need to go with 1) ?
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
Status: REOPENED → NEW
Product: PSM → Core
Whiteboard: [kerh-coz]
QA Contact: junruh → ui
Version: psm2.3 → 1.0 Branch
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6

I don't appear to be able to reproduce this problem with the 3.5 builds. 

I think this issue is resolved. Please re-open if there are still lingering exceptions.
Status: NEW → RESOLVED
Closed: 22 years ago15 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.