887407 - Suggest split up CA- certificates in Consumer- and ESR- Releases

Status: RESOLVED INVALID

(CA Program :: CA Certificate Root Program, task, P3)

Description

[t.schorpp]

The new split ESR- / Consumer Release scheme is great, it brings up many new possibilities and freedom like 

splitting up the CA certificates list in 

one for commercial organisations trusting in big auditor names, big money quality, paid audits, e.g like that:
https://bugzilla.mozilla.org/show_bug.cgi?id=343756#c54
distributed in ESR- Releases

and 

one for consumers / non-commercial organisations/ freedom users

to get the all the missing intermediate certificates required for S/MIME and *.org community CA root certificates in without hassle and big funds, requiring public review of "webtrust" and/or the ETSI- standard only, because only "closed" old-style "security by obscurity"- systems and organisations have a need and reason for those commercial auditors, OSS and open organisations have not, basically.

RFC. Happy discussions.

y
tom

Comment 1

[Al Billings [:abillings - ex-MoCo]]

Is this something we should think about?

Comment 2

[Kathleen Wilson]

If we were to split up the CA certificates list in some way (note that it is in NSS)...

It seems to me that the Consumer Release would be the one that needs the trust list of well-vetted and well-audited root certs, so that typical end users can browse to their favorite https sites without having to find and import the corresponding root certificates.

Maybe the ESR release doesn't need to include the NSS root cert store, because the enterprise organizations would have IT departments who could install their own preferred root cert store. But for those types of organizations it probably doesn't matter that the release comes with a default root cert store, because they probably over-ride it anyways. 


> to get the all the missing intermediate certificates ...

Mozilla doesn't include intermediate certificates by default.


Anyways, while I agree that there may be things we can do differently for the CA root list in ESR releases, I don't agree with this particular suggestion.

Comment 3

[t.schorpp]

(In reply to Al Billings [:abillings] from comment #1)
> Is this something we should think about?

Who is "we", please? 
And please explain the software security process named "think about", to "us", the public, Sir.

Do You mean "Brainstorming"? That's one of the things what I've called for here.

(In reply to Kathleen Wilson from comment #2)
> If we were to split up the CA certificates list in some way (note that it is
> in NSS)...

I know that, Thank you. 
BTW, the inclusion bugs are hard to search, because stored under 3(?) different (2 ancient) component/module names in the Bugzilla database.

> 
> It seems to me that the Consumer Release would be the one that needs the
> trust list of well-vetted and well-audited root certs, 

Sorry, Madame, but Your CA inclusion process and documents are still QUESTIONED as long KPMG and SwissSign do not answer in 343756 or the inclusion bug thread or You don't disclose Your process practice and details of the questioned steps to "us", the public reviewers, Your users who need to trust in Your products:
https://bugzilla.mozilla.org/show_bug.cgi?id=343756#c59

> so that typical end
> users can browse to their favorite https sites without having to find and
> import the corresponding root certificates.

Off- topic, "we"'ve not (yet) asked for removal of any CA and this would require opening a "KPMG Metabug" (about TÜV-IT I will take care later...).

> 
> Maybe the ESR release doesn't need to include the NSS root cert store,
> because the enterprise organizations would have IT departments who could
> install their own preferred root cert store. But for those types of
> organizations it probably doesn't matter that the release comes with a
> default root cert store, because they probably over-ride it anyways. 

Override with what? cacert.org, self-signed or snakeoil ? ;-)

Propably, but that's beyond Mozilla foundation's product responsibility and so off-topic here again, 
and "we", the majority of industry are small businesses, not NASDAQ or DAX. 
Is it them who Mozilla "serves" today, or did I get the "we" wrong?

> 
> 
> > to get the all the missing intermediate certificates ...
> 
> Mozilla doesn't include intermediate certificates by default.

"We" have noticed that, sadly:
https://bugzilla.mozilla.org/show_bug.cgi?id=887431

> 
> 
> Anyways, while I agree that there may be things we can do differently for
> the CA root list in ESR releases, 

Sorry, that's off- topic here again, please provide arguments and reasons on the bug's topic, Thank You.

> I don't agree with this particular
> suggestion.

Not surprisingly and respected, but thanks for the comments.

Comment 4

[Al Billings [:abillings - ex-MoCo]]

(In reply to t.schorpp from comment #3)
> (In reply to Al Billings [:abillings] from comment #1)
> > Is this something we should think about?
> 
> Who is "we", please? 

Mozilla.

> And please explain the software security process named "think about", to
> "us", the public, Sir.

No, that seems unnecessary. 

Please assume others are acting in good faith or you will find it hard to work with the community.

More "we" quotes, etc. are probably going to be ignored. Are you interesting in working with folks or are you interested in scoring points here?

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Hi Thomas,

Here is how regular Firefox releases work: we ship a new Firefox every six weeks.

Here is how ESR releases work: We take one of the normal Firefox releases, and we call it "ESR." So, at the beginning, the ESR and one of the normal Firefox releases are exactly the same.

Then, we keep updating normal Firefox like normal, every six weeks adding new features and bugfixes. But, we only update ESR with critical bug fixes. For the most part, we intentionally spend as little effort on ESR as possible, beyond keeping it safe to use.

We would never intentionally diverge in how ESR and regular Firefox works in the area of certificate processing. ESR will always have the same or some older version of the certificate stuff of regular Firefox, never different.

So, there's basically no way we would do this. I am going to close the bug as INVALID, which is a harsh word to use. I wish we had a friendlier vocabulary for such things in bugzilla.

Also, regarding your concerns about S/MIME: If we can find somebody interested in working on Thunderbird S/MIME support, I can give them some suggestions for how to resolve the issues you are having. I have been thinking of pre-loading some SSL intermediate certificates into Firefox sometime in the future. Thunderbird could potentially do the same for the S/MIME intermediates. But, for the most part, I do not work on Thunderbird so somebody else would have to do it. I am happy to explain to them how though.

Comment 6

[t.schorpp]

(In reply to Al Billings [:abillings] from comment #4)
> (In reply to t.schorpp from comment #3)
> > (In reply to Al Billings [:abillings] from comment #1)
> > > Is this something we should think about?
> > 
> > Who is "we", please? 
> 
> Mozilla.

Howdy.

> 
> > And please explain the software security process named "think about", to
> > "us", the public, Sir.
> 
> No, that seems unnecessary. 
> 
> Please assume others are acting in good faith or you will find it hard to
> work with the community.

Sorry, but I've sensed You trying to illegitimate my bug and debate request without stating reasons and in no practioneers way to respond to such, that was not "community" behavour, that was "royalty" behaviour IMHO.

> 
> More "we" quotes, etc. are probably going to be ignored. Are you interesting

Everybody has got the right to ignore anybody in the free world, I would never question that.
Looks like we don't like each others attitudes.

BTW, You may ignore possible issues of Your processes and products, but Your users will not, You're in competition, do You want to win it by compliance to freedom or to Kathleen's shareholder- "Enterprises"?

> in working with folks or are you interested in scoring points here?

Sorry for the "incompliance", maybe You want to recruit more "compliant" volunteers from KPMG then to get ideas for enhancements, but I'm pretty sure their "night-shift services" are very expensive.

Anyway, thanks for the feedback, I will "think about".



(In reply to Brian Smith (:bsmith) from comment #5)
> Hi Thomas,
> 
> Here is how regular Firefox releases work: we ship a new Firefox every six
> weeks.
> 

Reads alright so far.

> We would never intentionally diverge in how ESR and regular Firefox works in
> the area of certificate processing. ESR will always have the same or some
> older version of the certificate stuff of regular Firefox, never different.
> 
> So, there's basically no way we would do this. I am going to close the bug
> as INVALID, which is a harsh word to use. I wish we had a friendlier
> vocabulary for such things in bugzilla.

I accept any reasoned harshness and that's Your responsibility but why the hurry? 
Maybe others than *looks around* Mozilla Staff would like to comment, it's 04:30 CEST in Europe.

> 
> Also, regarding your concerns about S/MIME: If we can find somebody
> interested in working on Thunderbird S/MIME support, I can give them some
> suggestions for how to resolve the issues you are having. 

Well, first find enough organisations and users who are still interested in S/MIME after all the years of (budget, quality, user learning, marketing, deployment, etc) issues with CAs, PKI and it's implementations, looks like it's dying out silently down to a few geeks who can handle self-signed PKI and OpenPGP.

> I have been
> thinking of pre-loading some SSL intermediate certificates into Firefox
> sometime in the future. 

> Thunderbird could potentially do the same for the
> S/MIME intermediates. 

I don't think so because that bug has been already CLOSED WONTFIX 
https://bugzilla.mozilla.org/show_bug.cgi?id=657228#c2
I second that.

I would rather fall back to Kathleen's suggestion of letting downstream (Linux distribution security package maintainers) handle the CA inclusions, debian stable team (?) has already decided providing users ESR releases, but for free users/consumers which they are not intented, it seems, BTW.

Thanks for the audience.

Comment 7

[t.schorpp]

(In reply to Kathleen Wilson from comment #2)

> It seems to me that the Consumer Release would be the one that needs the
> trust list of well-vetted and well-audited root certs, so that typical end
> users can browse to their favorite https sites without having to find and
> import the corresponding root certificates.

I've got news for You:
http://www.nrca-ds.de/en/index_e.html

How many of this "best audited" CAs' CLASS4 /EV Roots have applied to You for inclusion and do not recommend "certified" proprietary closed source products to users of qualified sigs, although Thunderbird is open source and reviewable by dozens/hundreds/thousands of the best IT security practioneers worldwide?

See how this old style "secure by obscure/ closed source products certification"- nonsense is inhibiting progress in PKI and IT- security for more than 10 years now?

You can't win this competition by accepting their practices, they will destroy OSS in the long run.

Comment 8

[t.schorpp]

Link correction http://www.nrca-ds.de/en/ZDAliste_e.htm