437608 - Offer to edit trust on roots imported with user certs

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement)

Description

[Steve Roylance]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; MS-RTC LM 8)
Build Identifier: Firefox 3 Release Candidate 2

In some ways this is similar to Bug 185243.   GlobalSign has two root CA's with the same key material. One is currently embedded as a trusted root in FF3RC2, however the other, which is due to be embedded shortly currently issues Personal e-mail certificates.  Importing an e-mail cert, which is chained to the 2028 root, correctly installs the root into the store, however none of the properties are marked.  (i.e. use for identifying web sites)  Even when the root properties are edited the web site returns an error.   To highlight that there is no problem in directly importing the root, this was done and it works fine.  Both Root CAs can co-exist and it correctly chains to the 2028 root if a secure site is loaded.   It seems the Personal certificate import completely kills the root operations

Reproducible: Always

Steps to Reproduce:
1.Connect to https://www.globalsign.com and see that the site is chained to the root that expires in 2014.  Then obtain a GlobalSign e-mail demo certificate which is valid for 90 days. http://www.globalsign.net/secure_demo.cfm 
2. Apply using IE6/7 as we don't want to create directly in Firefox. Once you have the cert (e-mail challenge response), export to a PKCS#12
3. Import into FF3RC2 and then try to connect to https://www.globalsign.com
Actual Results:  
Even if you delete all the GlobalSign certificates from the store (They all reappear later as built in security objects), the browser always fails to connect to a globalsign secured site.

Expected Results:  
The performance of web sites should not be affected, but ideally as a new root cert is being added users should be asked if they trust for other purposes.  the current workflow is inconsistent.

Comment 1

[Steve Roylance]

I want to add that the roots in question are available here:-

Current Root embedded in FF3RC2
http://secure.globalsign.net/cacert/Root.crt

Proposed Root to be embedded  (Same key material)
http://secure.globalsign.net/cacert/Root-R1.crt 

thanks.

Comment 2

[Steve Roylance]

Additional testing and discussion with Nelson Bolyard shows that I need to rename the title of the bug to "inconsitency in certificate root import method."
and down grade severity. 

It still needs fixing to improve the user experience.

i.e. 

import a root by the front door (Directly) and the GUI presented to the user asked for trust bits to be set.

import a root by the back door and the trust bits are all set to off (even if it's an e-mail cert being imported).   Firefox should ask the user to set the trust bits for the new root.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

I confirm that this is an enhancement request. :)

I would summarize this RFE as follows:

When importing a "user" cert (a cert for which the private is locally held)
and its associated cert chain, if the chain includes a root CA certificate, 
that is not already known to the product, offer to let the user edit the 
trust on the imported root. (but that's too long for the bug summary field. :)

Comment 4

[Ron Adams]

Yes, this absolutely ought to be implemented. See the now-resolved Bug 527029 for a good use case.

Comment 5

[Kai Engert [:KaiE:]]

reassign bug owner.
mass-update-kaie-20120918

Comment 6

[Dana Keeler (she/her) (use needinfo) [:keeler]]

This isn't a feature that is widely applicable to Firefox users. As such, I don't think working on it would be a good use of our engineering resources. This might be better as an add-on.

Comment 7

[GlobalSign]

I agree.  This was a one-off requirement back in 2008.  Oh how the years flash by.  It's fine to close this down.   Thanks.  Regards   Steve