I'm responsible for a university site in Germany that is SSL secured,
with a certificate issued by a CA which is trusted by T-Systems. The
T-Systems cert is not (yet) included in firefox, the details can be seen
in Bug 378882.
I'm currently seeing more and more Firefox users migrating to version
3.0. Which is a good idea generally but leads to a problem: Firefox is
quite harsh about unknown certificates.
The reactions of the users are either of:
-installing the root CA in ff
-allowing an exception
-calling the helpdesk
-switching the browser
the latter more likely than the former. Consequently we see a slight
*decline in ff usage*. I'm an avid follower of mozilla since the early
days so I'm not happy with this development. Therefor I'd like to kindly
ask you to rethink your strategy and:
-stop provileging EV requests.
-start processing more requests.
There are currently 27 requests listed on the pending page. AFAICS there
were 3 requests approved in Q2/2008 (Network Solutions, DigiNotar,
Entrust). In Q1/2008 KISA and WISeKey discussion phase started and are
apparently stalled, a batch of already existing root CAs was upgraded to EV.
With a rate of 3 requests per quarter the requests would be dealt with
in over two years. This is way too long, considering that most of the
entries in the pending list are marked "information confirmed complete".
So please act now and quicken the pace on CA inclusion!
As it happens, I will be starting the first public comment period for
T-Systems today. If there are no problems with the request then we will
be able to approve the inclusion of the T-Systems root certificate in a
couple of weeks, and it will show up in a security update release of
Firefox later this year. (I can't give you an exact estimate because it
depends on NSS and Firefox development schedules.)
> So please act now and quicken the pace on CA inclusion!
We are doing what we can. However by design we do not simply
"rubber-stamp" CA requests. We have an official policy which was
developed through a process of community consultation, and we follow a
similar process of community discussion when considering CAs. We do have
more people now working on CA-related tasks (unlike previously when I
was the only person, and could do it only part-time). However the
process will never be quick IMO.
> As it happens, I will be starting the first public comment period for
> T-Systems today.
That really is good news!
> We are doing what we can. However by design we do not simply
> "rubber-stamp" CA requests. We have an official policy which was
> developed through a process of community consultation, and we follow a
> similar process of community discussion when considering CAs. We do have
> more people now working on CA-related tasks (unlike previously when I
> was the only person, and could do it only part-time). However the
> process will never be quick IMO.
I don't want you to wave through every request you receive. I think a
thorough inspection of every applicant is a good thing.
But if you look at it from the user experience side of things: The warning
you get for a certificate that is not trusted is really annoying. An EV
certificate that goes back to a root that is not EV enabled is not a
problem for the user experience.
So I think it's more important to get new CAs in than to enable old ones for
But that's just my 2 cents.
Frank, is there any reason why you can't have multiple candidate CAs having
their "public discussion periods" simultaneously?
Having watched this list for a number of months, I think I'm right in saying
that you're only allowing one at a time...in which case, how is having "more
people now working on CA-related tasks" actually improving your overall
Comodo CA Limited, Registered in England No. 04058690
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
I think one CA in public discussion per time just fine, however the
overall throughput could be accelerated. That would allow for a new CA
every two weeks or so.
This is something that I've seen also, and it makes me worried that the
current Fx solution *doesn't* really work as advertised.
The people see the warning, and the next minute, they start IE to access
Think about it : Instead of protecting them, Fx has pushed them to take
a decision that heightens their risk level, it would have been more
secure to let them go though the warning and access the site with Fx
rather than with IE.
No reason at all; in fact, technically we have two in public discussion
right now (GlobalSign and T-Systems). The major bottleneck is collecting
the CA information and getting the last 10% of questions answered.
Kathleen Wilson has some CAs that are in that stage now, and I've asked
Gerv Markham to start the process on two more. There are also a couple
of CAs that got bogged down at the public discussion stage earlier, and
I'm going to see if we can move them forward.
Thanks Frank. That's good to hear.
> in fact, technically we have two in public discussion
> right now (GlobalSign and T-Systems). The major bottleneck is collecting
> the CA information and getting the last 10% of questions answered.
> Kathleen Wilson has some CAs that are in that stage now,
Frank, in Bug #421946 Comment #15 you said:
"I'll proceed with the first public comment period once I figure out where
this request sits in the queue relative to other similar requests".
If the public comment/discussion periods are not the major bottleneck, then
can you explain why there has been no movement on this bug for over a month?
> and I've asked Gerv Markham to start the process on two more. There are also
> a couple of CAs that got bogged down at the public discussion stage earlier,
> and I'm going to see if we can move them forward.
Because I dropped the ball on that one, for which I apologize. I'll look
at it and start public discussion as soon as I can.
P.S. Incidentally, I have no problem whatsoever with CAs pinging me
directly (via email or phone or whatever) to remind me that their
requests need attention. Please feel free to do that if ever you should
Apology accepted. Thanks for picking the ball up again. :-)
> P.S. Incidentally, I have no problem whatsoever with CAs pinging me
> directly (via email or phone or whatever) to remind me that their
> requests need attention. Please feel free to do that if ever you should
> need to.
Frank, I think you mentioned in the past the ECC requests are lower on
the priority list.
Yes, but in this case the information collection work has already been
done, so I don't see any reason to arbitrarily delay starting public
Sure, no problem :-)
Just stated the fact about the priorities set by you...
We are on only one of almost 200 universities and research institutes in
Germany that rely on services provided by the "Deutsche Forschungsnetz
(DFN)" that operates a sub-CA of T-Systems CA. Each of that
organizations probably has a multitude of certificates. These work well
in "other browsers", so there's no need to invest further money in
certificates from other CAs.
I think you are implying something here which was neither said or meant:
Noone wants to have "every man and his dog" have a root ca in firefox.
But there are many CAs in the queue waiting to be processed by mozilla.
And those requests need to be dealt with!
Eddy Nigg schrieb:
> I think one CA in public discussion per time just fine, however the
> overall throughput could be accelerated. That would allow for a new CA
> every two weeks or so.
that's an excellent idea to schedule the start of a public discussion
phase every two weeks. Additionally it would be great to have a "public
queue", where every request that has passed the information gathering
process would be placed. So every CA would know exactly when public
discussion will start. It would make the whole process more transparent.
Well, the information gathering is only one of the steps (the first
actually) which has to be performed by the NSS team. The information has
to be evaluated carefully and most of the times requires additional
inquires. Frank has to make a decision of to submit the CA in question
to the public discussion. Needless to say that there isn't much point in
submitting a CA for discussion if there are uncleared issues are flaws
in their procedures.
But of course, the process could be and perhaps should be structured in
the most efficient way. Cheers!
> We are on only one of almost 200 universities and research institutes in
> Germany that rely on services provided by the "Deutsche Forschungsnetz
I know, however if you look at the costs of a new certificate vs. the
costs involved in training, waiting, applying workaround; purchasing a
new certificate would make sense.
That's why I wrote "passed the information gathering process" above.
Perhaps I should have wrote "successfully passed". My perception is that
the public discussion phase is the current narrow bottleneck (mostly
because nothing happened for several weeks). This could be avoided if
there was a public schedule for requests in the queue.
> I know, however if you look at the costs of a new certificate vs. the
> costs involved in training, waiting, applying workaround; purchasing a
> new certificate would make sense.
It would have made sense over a year ago when the whole process was
started - If Mozilla had said: "We wont get it in for over a year". But
at that time it was never clear that it would take more than a year.
That's why it would be good to get more "reliability" into the process
of including new root CAs.
DFN <-> German universities have already complete procedures &
infrastructure for new certificates (all requests are considered by
subnet management group, only users which are employees of the
university can request a certificate, department head has to approve,
IT department of the university checks validity and submits to next
next higher instance, ..) - so there is an "easy" unified and web-
based way - who has the budget to rebuild/customize this for a new
Ohoommm, please note that the audit of T-Systems was completed only at
the end of the previous year, which is usually a bad time anyway
(holidays, vacations etc). Subsequently the process was started
thereafter in January and a half year is typical for processing an
I don't think that you and all the others have a right to complain.
Other CAs waited for at least that period as well if not longer - at a
time when less then ten CAs were processed per year. Where has this CA
been during all the previous years, but only recently considered
applying for inclusion!?
I view the latest remarks in the bug and at the mailing list rather
counter-productive and doesn't impress anyone here really.
just to make it clear: I'm not working for a CA, I am just a user.
Eddy Nigg schrieb:
> Ohoommm, please note that the audit of T-Systems was completed only at
> the end of the previous year, which is usually a bad time anyway
> (holidays, vacations etc). Subsequently the process was started
> thereafter in January and a half year is typical for processing an
> inclusion request.
There has been an earlier audit. Gerv raised concerns about that audit
in comment #12, they were adressed in comment #13. In july all
information were gathered and in august the information was finally
"confirmed complete". IMHO the public discussion phase could have
started then, but it wasn't. That is what I found difficult to understand.
I haven't reviewed the bug yet (will do so this weekend), but it seems
to me that the audit you mentioned is a self-audit. Anyway...T-Systems
has apparently completed a acceptable audit and is right now in the
first comments period. I guess everybody can relax now and keep fingers
You didn't get what I meant, but I didn't help by not saying immediately
what kind of solution I favored. I didn't do that because I didn't want
to mix the problem with the specific solution I was thinking of.
I'd like to say first that unrecognized CA is only one the possible
cause for Firefox displaying the new "access denied" screen, and my
concern is about this screen, not about the specific point of
In the Fx 3 beta, when I first saw this screen and the complex procedure
required to proceed through and access the site, I thought it was a way
to make sure people would think carefully about what they were doing
instead of just clicking "Ignore warnings", and I was OK with the idea.
But later I found out that in practice people, even quite smart people,
did not understand how to get through this screen, *and* would start IE
to access the site instead of continuing with Firefox.
Now here comes Thorsten who has access log statistics that prove the
reality of this phenomen.
So the solution I'd be in favor of is :
- Declare the current SSL error screen a failure
- Let people go through the SSL error screen easily, just like in Fx 2
- After they have gone though the SSL error screen and as long as they
stay on this SSL site, display a non-removable warning bar that says
"This site is not trusted, do not submit sensible information !".
Make it red, flashing, anything required so that ordinary people will
feel very uneasy at the idea of ignoring it.
- (I see that as a not really required option): Have some complex
procedure that allows to remove this warning bar, similar to the current
one to avoid the error screen.
> So the solution I'd be in favor of is :
> - Declare the current SSL error screen a failure
> - Let people go through the SSL error screen easily, just like in Fx 2
> - After they have gone though the SSL error screen and as long as they
> stay on this SSL site, display a non-removable warning bar that says
> "This site is not trusted, do not submit sensible information !".
> Make it red, flashing, anything required so that ordinary people will
> feel very uneasy at the idea of ignoring it.
> - (I see that as a not really required option): Have some complex
> procedure that allows to remove this warning bar, similar to the current
> one to avoid the error screen.
That's a nice idea. One problem I have with the current implementation
is: A user gets a big warning about an unknown and untrusted
certificate. In the next step, he can add an exception. That process is
a bit difficult. And it should be difficult. I totally agree with that.
But if you go through the process of adding an exception (and don't
think about it, as the average "Joe User" most likely does), the
exception is stored permanently. You won't get a warning the next time
you visit the site.
I think the solution that Jean-Marc outlined above would make some
sense: It would make it a bit easier to visit certain sites, but disturb
permanently if someone visits a site that has no trust anchor in firefox.
> One problem I have with the current implementation
> is: A user gets a big warning about an unknown and untrusted
> certificate. In the next step, he can add an exception. That process is
> a bit difficult. And it should be difficult. I totally agree with that.
> But if you go through the process of adding an exception (and don't
> think about it, as the average "Joe User" most likely does), the
> exception is stored permanently. You won't get a warning the next time
> you visit the site.
That's on purpose.
> I think the solution that Jean-Marc outlined above would make some
> sense: It would make it a bit easier to visit certain sites, but disturb
> permanently if someone visits a site that has no trust anchor in firefox.
There's a great deal of evidence, and consensus in the UI and security
community, that UI error/warning dialogs that are easily dismissed condition
users to dismiss them without thinking. Users who do it often enough
actually reach a point where they are no longer consciously aware that
they're experiencing the dialog, nor that they're actively dismissing it.
When that happens, the error dialog loses all value. It might as well
not exist, because it has no effect.
The fact that people are now noticing the dialogs, and reacting to them,
means that the UI change is having at least some of the desired effect.
It's making people pay attention to the dialogs.
It's a sad fact that many people simply refuse to believe, or are incapable
of believing, that there could be any downside to overriding all such
errors, and will go to any length to do so. But that doesn't mean we
should stop trying.
Hixie jokingly made a similar point over IRC back in November, with
regard to phishing protection:
<Hixie> i think i just found a semi-serious issue with the phishing
protection in firefox
<Hixie> i went to a site that triggered the warning
<Hixie> and my immediate reaction (without really thinking) was "oh i
wonder why that is blocked, let's have a look" and i immediately opened
it _in IE_.
<Hixie> possibly the worst thing i could have done.
(source: http://quotes.burntelectrons.org/3129 )
Please compare the warning that you receive when you go to
with phishing protection enabled with the warning you get if you go to a
site with a certificate mozilla does not trust. What I do like about the
phishing wanrning is that it stays on screen even if you ignore the
warning and visit the site.
This is exactly the kind of thing I would like to see for SSL, and there
is no reason why the strategy for bad SSL is different from the strategy
for malware/fishing. I hope the non existing PSM team ;-) can take that
into consideration. Well, I'll copy this message to mozilla.dev.security
because the people who implemented the new SSL page might be there (as
well as more people who have the power to reconsider this decision).
Now if we go in some more details, in the fishing/malware protection
feature, the initial screen is coming back for every link on the site,
which I think is a bit too much.
Try going to the page below and follow some links at the top to see that
(you can not test that with its-a-trap.html, because there's no link
inside the page to go to another malware flagged page):
And also it seems that there is a bug that makes some pages not display
the warning bar after going through the warning. Try this one to see this :
It just happens that in my initial test with the malware protection, I
had met this two behaviors which made me think that my idea was
different from the malware protection mechanism currently in place.
But after all, it's really almost exactly the same with the difference
of suppressing the possibility of easily removing the warning bar.
PS: I strongly suspect www.km-jsw.gov.cn has been flagged by error (or
else we need to talk with the chinese government), which make it a great
test site. But I don't know for sure, so access it at your own risks. If
you need other malware site addresses for testing,
http://www.malware.com.br/#blocklist has a useful list.