Re: Proposed MF certificate policy and FAQ
I definitely agree with benefits and risks being the key factor to the policy. 4.1 is merely a corollary of the benefits requirement. 4.2 is only necessary to evaluate the risks requirement. 4.3 should add a requirement that the data be compatibly licensed. I do believe we need more details somewhere on key risk factors. In the details of policy FAQ: The How will the Mozilla Foundation decide entry significantly understates the risks side of things. I believe the word undue should be removed, as it suggests Mozilla will accept a fairly high level of risk per CA. Remember, every CA we add increases the risk, as an attacker only needs to break one of them to succeed. The entry should probably list risks separatly from benefits. The discontinuation entry should mention a change in the risk/reward evaluation as being the most likely reason. The free certs section goes into a digression about email certs. This information, if it belongs anywhere, belongs in the how will decide entry. The entire second paragraph is redundant with that entry. In the Exactly what information section, I don't entirely agree with the continuity of CA operations requirement. While continuity requirements for any CRL and/or OCSP service might make sense, there is no risk to mozilla users if a listed CA fails to continue issuing certs. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Frank, I think you have just opened a big can of worms with this Certificate policy. - It should be called a Mozilla Certificate authority policy, not Certificate policy. I don't think there is any plan to include any non-CA certificates. - I think the term default certificate database is somewhat ambiguous. Technically, there is a built-in PKCS#11 module containing a database of root certificates and trust. This module is separate from the certificate database associated with each Mozilla profile. In fact, the root certs module/database can be removed by the user altogether and security in Mozilla can continue to function without it. I just had to point that out. The CA certs don't get added to the profile certificate database, unless their trust is modified. - I am not a lawyer, but I really think you are underestimating the liability issues for the foundation if it chooses to select certificates. Has the Mozilla Foundation hired a lawyer to look at the issue to make a determination of the liability risks the security policy exposes the Foundation to, or is the Foundation in the process of hiring one ? I would love to be wrong, but I think this is definitely something that needs to be looked at by a lawyer, because it's the sort of thing that could take down the foundation if not done very carefully. Just because Mozilla has a legal disclaimer does not mean that you won't be sued. Commercial software comes with plenty of disclaimers, too. - As the (soon-to-be-former) AOL/Netscape employee who has been doing most of the check-ins to the built-in root certs for NSS in recent years, I know I would not feel comfortable at all with a policy that is so arbitrary and void of verifiable objective criteria - section 4.1 in particular. - The current official certifications for commercial CAs such as WebTrust are extensive and expensive. They don't match 1 to 1 with the spirit of the Mozilla foundation, in that they may be overly restrictive on who can join the party. So they shouldn't be a sine qua non condition for inclusion. - Most users don't understand PKI security and are not able to make CA certificate trust decisions. And it would be indeed laughable to except them to be able to do so with a pop-up that simply shows a few fields in the certificate. Ever tried to verify a root CA certificate just by looking its contents ? What did you do, call a company's 800 number and check the fingerprint and public key to make sure it matched ? The point is, you need an external source of trust to help with the decision. There is no one-size-fits-all list of trusted CAs. That's why trust is editable, and not static. People are using Mozilla in diverse environments. I personally use Mozilla as if it were commercial software, for personal needs such as banking, and wouldn't expect it to include MyFriendlyNonProfitCAWhoCan'tAffordWebTrust, Joe'sPersonalCA, or MilitarySecretCA. In the later two cases, the end-users are savvy enough to install the certificates themselves, before they actually start to use them (ie. long before the browser pops-up an unknown CA - do you want to trust it? pop-up). You on the other hand might want to use MyFriendlyNonProfitCAWhoCan'tAffordWebTrust without being presented a trust pop-up that is very hard to act upon. Unfortunately, I don't know of any organization that will vouch for CAs in the MyFriendlyNonProfitCAWhoCan'tAffordWebTrust category, but it sounds like that's what you need here. I don't think it can or should be the Mozilla foundation itself doing it through its policy. I also don't think they should be blanket included together with all the commercial CAs that passed a certification. I think MF should defer to such a CA verification organization when one is created. When it does, these CA certs can be compiled into a separate PKCS#11 module containing only certificates CAs in this category. The Mozilla browser could then prompt the user for the security policy he wants to adopt when creating his profile : there could be a checkbox for the commercial CAs, which would basically be the current built-in module, and another checkbox for MyFriendlyNonProfitCAWhoCan'tAffordWebTrustCAs(for lack of a better term) who did not go through the WebTrust (or other) commercial certification required to be included in the first group. The effect of each checkbox would be to load or not load a given PKCS#11 modules containing a set of trusted CA certificates. 0, 1, 2 or n PKCS#11 modules containing trusted CA certificates can be loaded in Mozilla in any one profile. This way, the user makes the decision of which CAs he trusts on a rational basis when creating his profile with a question that he can answer. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
- I am not a lawyer, but I really think you are underestimating the liability issues for the foundation if it chooses to select certificates. Has the Mozilla Foundation hired a lawyer to look at the issue to make a determination of the liability risks the security policy exposes the Foundation to, or is the Foundation in the process of hiring one ? I would love to be wrong, but I think this is definitely something that needs to be looked at by a lawyer, because it's the sort of thing that could take down the foundation if not done very carefully. Just because Mozilla has a legal disclaimer does not mean that you won't be sued. Commercial software comes with plenty of disclaimers, too. Even if MF relies on a 3rd party whats to absolve them of all responsibility, after all they still included the certificate regardless of any 3rd party saying it was ok, and as previously stated, webtrust/AICPA are a bunch of accountants, with the current certificate practices resolving around commerce, rather then the 100's of other purposes certificates can be used for but are too expensive to get and use. In any case what has webtrust/AICPA done in light of blatant mistakes by companies they have approved? Without a consequence what is to stop any CA, commercial or otherwise from caring who they issue certificates to as long as they make a buck from it? ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On criteria for trusting public root CAs
Nelson B wrote: Jean-Marc Desperrier wrote: I like the approach of you can choose the list of root ca you accept, and there is a proposal only list with Mozilla. See the thread with the subject Should mozilla's built-in CA list include untrusted CAs? Sounds to me like you might favor that idea. Yes? Please comment in that thread. It's not the same thing, and the implementation might rely on completely different elements. I'll try to describe the idea more in details in a separate thread. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Even if MF relies on a 3rd party whats to absolve them of all responsibility, after all they still included the certificate regardless of any 3rd party saying it was ok, Ignoring the semantics of any particular legal threat, it may be worth considering creating a single corporation, wholly owned by the Foundation, that is given total responsibility for all CA issues including creating the default list. This is a well known ring-fencing or firewalling technique, and is generally quite acceptable if clearly documented (and the parent Foundation never makes any independent judgement or decision). It would mean that any suit against the single corporation that made all the decision would not threaten the rest of the project. iang ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: publish NSS on Sourceforge?
Thank you. Is it possible to just set up an information page for NSS on Sourceforge, which would contain links to the NSS page on www.mozilla.org, the NSS bugs in bugzilla.mozilla.org, and the mozilla.crypto newsgroup? Maybe sourceforge is overkill. If there is some other catalog of open source software (like freshmeat.net?), we can submit an entry for NSS. OK I have assembled (read stolen ;-) some info about NSS. Is this ok to publish? Name: Network Security Services (NSS) Presentation: (is this text ok?) Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. NSS is dual-licensed under the Mozilla Public License and the GNU General Public License. Link: (is this link stable?) http://www.mozilla.org/projects/security/pki/nss/ Directories: (is there more?) freshmeat.net osdir.com I just don't want to incur the burden of maintaining mirrored cvs repositories or download sites. Just links to resources on mozilla.org. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Julien Pierre wrote: Frank, I think you have just opened a big can of worms with this Certificate policy. - It should be called a Mozilla Certificate authority policy, not Certificate policy. I don't think there is any plan to include any non-CA certificates. I originally called it the Mozilla CA Certificate Policy, but changed it just to have a shorter name. I can certainly change it back. But to play devil's advocate: It is 100% guaranteed that we would never ever want to include a non-CA cert in Mozilla? - I think the term default certificate database is somewhat ambiguous. Technically, there is a built-in PKCS#11 module containing a database of root certificates and trust. This module is separate from the certificate database associated with each Mozilla profile. In fact, the root certs module/database can be removed by the user altogether and security in Mozilla can continue to function without it. I just had to point that out. The CA certs don't get added to the profile certificate database, unless their trust is modified. I am open to using different terms and a simple way to explain what actually is done. Suggestions welcome. - I am not a lawyer, but I really think you are underestimating the liability issues for the foundation if it chooses to select certificates. That may well be. As I said before, I will certainly submit any proposed policy to the Mozilla Foundation for approval by the appropriate people (MF officers, and the MF board if necessary), and recommend that they have appropriate legal counsel review the policy. But I am not going to attempt to do the lawyers' job for them; that is not what I'm being paid to do (well, I'm not being paid anything at all, but you get the point). Please forgive me now if I rant for a bit: I'd like to have a conversation about mitigating security risks, but people keep dragging me off to start a conversation about legal risks. Why is that? What is it about CA certs (as opposed to a host of other important security-related issues) that prompts this relentlessly single-minded focus on bad things that can happen from a legal point of view? (I am tempted to say, because with PKI and CAs the lawyers got there first, but I'll hold that thought for now.) You may recall that I was the lead on mozilla.org creating a policy on addressing and disclosing security vulnerabilities in Mozilla. We had plenty of hard-hitting discussions on how best to mitigate security risks to Mozilla users. We spent very little time (if any) worrying about how to mitigate legal risks. But the types of security vulnerabilities under discussion were fully as serious as the types of vulnerabilities resulting from breakdowns in the CA cert scheme. (In fact on first impression I'd take the vulnerabilities to be formally equivalent: a Mozilla exploit allowing file writing could lead to CA certs being invisibly added and/or trust flags reset, and a bad CA cert, e.g., for object signing, could lead to a user downloading exploit code.) I guess the difference is that with normal vulnerabilities we've internalized the idea that license liability disclaimers do at least a reasonable job of mitigating any legal risks to developers and distributors, and we focus primarily on security risks. If we consider things like formal security certifications (e.g., Common Criteria), it's as a potentially-useful option for customers who care about it, but of a somewhat different nature than standard designing for security, and not a substitute for it. On the other hand with CA certs we seem to get paralyzed by the sheer amount and complexity of the legal paperwork and audit frameworks, to the point where we feel we can't move without consulting a lawyer. Past a certain point I just don't understand why this is the case. I don't understand why we have to consult a lawyer before deciding whether to add a CA cert, and not when deciding how to best configure Mozilla security options for the typical user. (And in fact isn't the former just an special case of the latter?) As a final point, I've actually looked at the ABA documents, and I can't figure out how their whole legal discussion applies in the case of something like Mozilla. IIRC it is organized around the concept of CAs, certificate holders, and relying parties. We are certainly not a CA and not a certificate holder. It's possible that we would be considered a relying party, but that role really seems to be played by Mozilla users, e.g., who connect to certificate-presenting web sites and so on. I guess we could be considered a sort of agent acting on behalf of a relying party, but I don't recall the ABA documents addressing that situation. I'd be interested in any online references that actually discuss this. Anyway, that's the end of my rant (at least for now). - As the (soon-to-be-former) AOL/Netscape employee who has been doing most of the check-ins to the built-in root certs for
Proposal : Installable trusted CA list
This proposal is related to all the discussion about how to select the correct list of root CA for Mozilla, but is a slightly different way of looking at things. The idea is that there is no way of selecting a single list of CA that will make everybody really happy. On the other hand, any solution where the use has to decide on a one by one CA level is not manageable. So this proposal would be that Mozilla would get away of imposing to all users a single built-in trusted CA, but instead distribute several trusted CA list, with a description of the origin of each list, how it is created, and let the users decide what is best for them. This list should of course be made short and in a way so not to confuse the users. The first item in the list would logically be the AICPA list, with the indication it's the same list as IE. Then could come a more open list, that a CA could get it without paying as much as in AICPA list, and that maybe could reject some AICPA members based on the motive of recorded misbehavings. Technically if this is done during install, the install just has to replace the default built-in cert file with the one selected. So, this does not ask for change in PSM/NSS. Maybe some more items on the list would be useful, like same as old Netscape 4.7. The list might end with a link to a page having a more comprehensive list. Of course, that page would then include instructions on how to change the trusted list after installation. (or/and have an about:trust that points to this page ?) PS: In fact, the mechanism I propose here is not something I first thought about in this context. The problem of not been able to choose a single universal list is similar in Apache for the file extension/Mime-type association in mime.conf file, that today has very selective filters for entry. They make many people, and in fact even Mozilla, unhappy. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On dividing CA selection effort between pre and post release
John Gardiner Myers wrote: Jean-Marc Desperrier wrote: But there is no code to extract the CRLDP from the cert in Mozilla, it's not even displayable in Mozilla. Have you tried a trunk build? How recent ? It's not there in the 20040202 nightly. If there were someone working on PSM, I wish it would have a good place on his todo list. There is someone working on PSM, but progress is glacial due to the multiple-week review latencies. Excellent ! This is not the word that was going until very recently. I hope you did not understand what I said as critiquing the lack of developers, this was just a sad reality for me ... ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
PSM development
Jean-Marc Desperrier wrote: How recent ? It's not there in the 20040202 nightly. I'd rather not spend the time to look it up. For now, you still have to read the contents of the field as DER. Excellent ! This is not the word that was going until very recently. The statements I have seen recently have been that PSM development is not funded. Which is still true. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: publish NSS on Sourceforge?
Emil Assarsson wrote: My point is just that I think NSS could gain some by standing out on it's own. I think that a lot of developers think that NSS is hard to user simply because that it is a part of Mozilla. I think many think it's hard to use because they do not have enough doc on how to use it. Or they don't really know how to access that doc, because in truth the amount available is not neglectable. Taking time to write doc in the line of What I wish I had known when I first used NSS would probably be the best thing. And that could be on a NSS dedicated page, on Sourceforge or elsewhere appropriate, that would very probably link to some of the ressource already there on mozilla.org. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: How to use a free comodo cert with AIM
Nelson B wrote: Would someone please test these steps for me and tell me if you have any difficulties with them? I wrote this page up a couple weeks ago and need someone to test my directions for me. I wrote some similar instruction pages, and from that experience, I think you should reformat this as a succession of short HTML pages, with screen captures. With such level of detail, this pure text format will look very tedious whatever you do. Even if the html pages will be longer because of the screen capture, it will be easier to follow the instructions that way. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Julien Pierre wrote: [...] A lot of OCSP servers have been incorrectly (and that includes Verisign's). [...] A significatn problem with Verisign is that some time ago, they were including the OCSP extension for some people who had not paid for OCSP, so the responder would refuse to tell the state of the cert. Unfortunately Mozilla would then refuse to connect to the site, which made OCSP quite unusable. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposal : Installable trusted CA list
Jean-Marc Desperrier wrote: This proposal is related to all the discussion about how to select the correct list of root CA for Mozilla... So this proposal would be that Mozilla would get away of imposing to all users a single built-in trusted CA, but instead distribute several trusted CA list, with a description of the origin of each list, how it is created, and let the users decide what is best for them. This is clearly the way to do it. In addition, the format of such list should be defined and documented, so that special-interest user communities can become their own trust-list publishers. Roger ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Frank Hecker wrote [in part]: As noted in prior discussions, the Mozilla Foundation and mozilla.org staff are considering adopting a formal policy regarding selection of new CA certificates for inclusion in the default certificate database distributed with Mozilla, Firefox, Thunderbird, etc. After reviewing the discussion in this thread (and other threads), I must conclude that the whole approach to developing a policy is flawed. A policy should represent specifics based on a more general philosophy, but I don't think the philosophy itself is clear in this case. The first question that must be answered is: Why continue developing Mozilla? I would hope the answer does NOT revolve around an exercise in computer science but instead reflects a desire to create a high-quality software application for personal and commercial use -- an application for the real world. If Mozilla is intended for real use, the next question is: Who uses Mozilla? Given my hope for the answer to the first question, the answer to this question should be: Anyone who uses the Internet. This means that most Mozilla users are not truly sophisticated software experts. The answer to the second question raises the next question: In that context, how are (not how should) CA certificates used? Clearly (at least to me), the answer is: The primary and most important use of a CA certificate is to provide the Mozilla user with assurance that (1) a critical Web site is indeed what it purports to be and (2) sensitive data communicated to a Web server travels across the Internet securely. If this chain of questions and answers is valid, then the Mozilla Foundation has an obligation to those who use its products to authenticate not only the validity of each CA certificate in the default database but also the integrity of the CA's process of issuing and signing Web server certificates with that CA certificate. This requires specific, objective, and verifiable criteria for authenticating both validity and integrity. I advocate third-party audits because those criteria already exist and are already being applied through such audits. No, this does not mean only WebTrust audits. Earlier in this thread, I cited a California state regulation that specifies either WebTrust or SAS 70 audits. (See Sections 22003(a)6(C) and 22003(a)6(D) under http://www.ss.ca.gov/digsig/regulations.htm#22003.) Further, that regulation provides criteria for accepting other accreditation criteria. However, until other criteria can be clearly identified and documented, the WebTrust and SAS 70 audits are the only trustworthy and reliable bases for accepting CA certificates. In the end, the real question is: Can we trust and rely on the CA certificates in the Mozilla default database to protect our privacy and our assets? The answer to that question will determine whether we can trust the Mozilla Foundation, which needs to clarify the underlying philosophy upon which the proposed policy should be based. Of course, my original assumption -- my hope for the answer to the first question -- might not be valid. In this case, Mozilla is merely an interesting toy; and I will then have to rely on some other browser for online banking and other critical Web uses. -- David E. Ross http://www.rossde.com/ ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
David Ross wrote: The first question that must be answered is: Why continue developing Mozilla? I would hope the answer does NOT revolve around an exercise in computer science but instead reflects a desire to create a high-quality software application for personal and commercial use -- an application for the real world. If Mozilla is intended for real use, the next question is: Who uses Mozilla? Given my hope for the answer to the first question, the answer to this question should be: Anyone who uses the Internet. This means that most Mozilla users are not truly sophisticated software experts. (It may be that the Mozilla users in the majority are not sophisticated. But, that does not mean that the software is written for them.) The answer to the second question raises the next question: In that context, how are (not how should) CA certificates used? Clearly (at least to me), the answer is: The primary and most important use of a CA certificate is to provide the Mozilla user with assurance that (1) a critical Web site is indeed what it purports to be and (2) sensitive data communicated to a Web server travels across the Internet securely. (This is not clear at all. I think it rests on a number of false assumptions, but those are quite hard to describe in a quick email, so I'll skip that here.) If this chain of questions and answers is valid, then the Mozilla Foundation has an obligation to those who use its products to authenticate not only the validity of each CA certificate in the default database but also the integrity of the CA's process of issuing and signing Web server certificates with that CA certificate. How do you conclude that? As users don't pay anything, there can not be much of an obligation of any form, let alone something as sensitive as the validity of a signature chain (something that evidently other competitors have also failed to treat as obligations). No, this does not mean only WebTrust audits. Earlier in this thread, I cited a California state regulation that specifies either WebTrust or SAS 70 audits. (See Sections 22003(a)6(C) and 22003(a)6(D) under http://www.ss.ca.gov/digsig/regulations.htm#22003.) Further, that regulation provides criteria for accepting other accreditation criteria. However, until other criteria can be clearly identified and documented, the WebTrust and SAS 70 audits are the only trustworthy and reliable bases for accepting CA certificates. Is there a specific reason why Mozilla should decide to write and distribute its software according to these regulations? It seems to be a bad idea, on the face of it... In the end, the real question is: Can we trust and rely on the CA certificates in the Mozilla default database to protect our privacy and our assets? The answer to that question will determine whether we can trust the Mozilla Foundation, which needs to clarify the underlying philosophy upon which the proposed policy should be based. No way. This is FUD. Just because the default list of certs might have some flaws does not mean that we or users or anyone should not trust the Mozilla Foundation. The Foundation is under no obligation to provide a list to you or anyone. Trying to shame them into providing your list, one that you can trust, will achieve nothing for Mozilla or the users. This is easy to see - if you could pick the list, as trustworthy, then so could anyone else. As there is a debate, it is clear that picking the list is a vexing issue. Thus, no room for FUD tactics. Of course, my original assumption -- my hope for the answer to the first question -- might not be valid. In this case, Mozilla is merely an interesting toy; and I will then have to rely on some other browser for online banking and other critical Web uses. iang ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
RE: On turning CRL and OCSP checking on by default.
As I mentioned in a pervious email...this has been fixed. Alex -Original Message- From: Jean-Marc Desperrier [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 11, 2004 10:24 AM To: [EMAIL PROTECTED] Subject: Re: On turning CRL and OCSP checking on by default. Julien Pierre wrote: [...] A lot of OCSP servers have been incorrectly (and that includes Verisign's). [...] A significatn problem with Verisign is that some time ago, they were including the OCSP extension for some people who had not paid for OCSP, so the responder would refuse to tell the state of the cert. Unfortunately Mozilla would then refuse to connect to the site, which made OCSP quite unusable. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla- crypto ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Changes to ocsp.verisign.com
On February 23, 2004, VeriSign will update the OCSP service currently available at http://ocsp.verisign.com/ to allow for the support of extremely high transaction volumes. These changes are being implemented to ensure our OCSP services continue to scale and perform as new applications and platforms which support OCSP are introduced into the marketplace. Note that this change only effects VeriSign and Thawte retail products including SSL/TLS and code signing certificates. Enterprise OCSP services available at http://onsite-ocsp.verisign.com/ are not effected by this update. The changes we are making to scale our OCSP responder service will result in the discontinuation of support for the nonce extension. With this new OCSP responder service, clients should not expect a nonce in the response to a request that contains a nonce. Details regarding responder behavior, how clients can ensure a response is fresh, additional security considerations and suggested caching behavior has been documented in an internet-draft co-authored by VeriSign and Microsoft available at http://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-profile-00 .txt VeriSign's tests have shown that most of the widely deployed OCSP clients and toolkits are not effected by this change. However, because our OCSP services may be used in other applications there is the possibility that some users may be impacted by this update. For more information see http://www.verisign.com/support/vendors/ocsp.html. Regards, Alex [EMAIL PROTECTED] ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Frank Hecker wrote: Julien Pierre wrote: - It should be called a Mozilla Certificate authority policy, not Certificate policy. I don't think there is any plan to include any non-CA certificates. I originally called it the Mozilla CA Certificate Policy, but changed it just to have a shorter name. I can certainly change it back. Well CA cerificate is somewhat redundant (it includes Certificate twice). I would say Mozilla [built-in] Certificate Authority Policy would be a good name. But to play devil's advocate: It is 100% guaranteed that we would never ever want to include a non-CA cert in Mozilla? It is not guaranteed. You can use the built-ins module for anything you want, including negative trust on some known compromised popular server certs (ie. like a global CRL). But I would not recommend such use. I think in practice you would only ever want root CA certs on it. - I think the term default certificate database is somewhat ambiguous. Technically, there is a built-in PKCS#11 module containing a database of root certificates and trust. This module is separate from the certificate database associated with each Mozilla profile. In fact, the root certs module/database can be removed by the user altogether and security in Mozilla can continue to function without it. I just had to point that out. The CA certs don't get added to the profile certificate database, unless their trust is modified. I am open to using different terms and a simple way to explain what actually is done. Suggestions welcome. Well, I don't know yet what the right name should be, but if we choose to have several modules with different set of certs, then the distinction becomes more important since there won't be a single default certificate database. (MF officers, and the MF board if necessary), and recommend that they Make that require. Please forgive me now if I rant for a bit: I'd like to have a conversation about mitigating security risks, but people keep dragging me off to start a conversation about legal risks. Why is that? What is it about CA certs (as opposed to a host of other important security-related issues) that prompts this relentlessly single-minded focus on bad things that can happen from a legal point of view? (I am tempted to say, because with PKI and CAs the lawyers got there first, but I'll hold that thought for now.) Does it really need spelling out ? If you have a rogue or compromised trusted CA in Mozilla, which willingly signs fake server certificates, that opens the door to all kinds of scams, where Mozilla users will think they are doing business with somebody when in fact they are not. Remember that one of the most common uses of SSL is for financial transactions. If Mozilla users suffer financial losses due to a rogue trusted CA, you can bet they will sue whoever approved that trusted CA, disclaimer or not. So it is in the interest of the Foundation not to make the decision itself. Past a certain point I just don't understand why this is the case. I don't understand why we have to consult a lawyer before deciding whether to add a CA cert, and not when deciding how to best configure Mozilla security options for the typical user. (And in fact isn't the former just an special case of the latter?) You have a point. And I think the MF should have a good answer to that question, since it distributes all the security code, not just the CA certs. The liability situation is different now that there is an MF, rather than a corporate distributor of the open-source code. - As the (soon-to-be-former) AOL/Netscape employee who has been doing most of the check-ins to the built-in root certs for NSS in recent years, I know I would not feel comfortable at all with a policy that is so arbitrary and void of verifiable objective criteria - section 4.1 in particular. Then let's come up with some verifiable objective criteria -- but let's focus on criteria that mitigate security risks, as opposed to legal risks. The lawyers can take care of themselves. The policy will have to address both risks, for the sake of the MF and the contributors editing the database. - Most users don't understand PKI security and are not able to make CA certificate trust decisions. And it would be indeed laughable to except them to be able to do so with a pop-up that simply shows a few fields in the certificate. Ever tried to verify a root CA certificate just by looking its contents ? What did you do, call a company's 800 number and check the fingerprint and public key to make sure it matched ? The point is, you need an external source of trust to help with the decision. There is no one-size-fits-all list of trusted CAs. But of course the problem is that in this respect the Mozilla Foundation offers Mozilla as a one-size-fits-all product, in large part as a consequence of the design of the underlying security/crypto mechanisms. We can't easily offer Mozilla for casual Internet
Re: Proposed MF certificate policy and FAQ
My take on this is, the policy should be carefully examined before it is decided, it's not something to do in a hurry just because there are a couple CAs that are shouting that they want to be included right away. It may well be that the right policy requires some work to actually implement. I kind of agree with Franks statement about security issues relating to mozilla Vs this one, surely they are directly related a lot more to MF liability then any CA issue, as the CA themselves should be liable not the MF for any poor judgment of certificates issued. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Should mozilla adopt a non-binary trust model for CAs?
Nelson B wrote: I would propose that when viewing a web site with a low assurance root CA, some kind of large ugly icon be displayed in the chrome, with a tool tip that says something like This web site may or may not be who they say. I would propose that there be a way to display the name branding of the signing CA in the chrome when accessing a secure site, then letting commercial CAs fight it out in the marketplace trying to: - Create a consumer perception of trust - Convince merchants that consumers may care about how trusted a CA is thus aligning the incentives of the players in the transaction. Also, it's much better to allow customers to determine how trustworthy a CA is than relying on / creating a dependency on the editorial judgement of the software developers. Among other things, what will you do when CA X, which offers cheap certs and has a has a crappy validation process, asserts that they have a high assurance CA and threatens you with libel if you don't agree? - Tim ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Duane wrote: I couldn't find the reference off hand in your postings Frank but a thought occurred to me that rather then removing CAs immediately, make a small code change to reject any certificates issued by a CA after a certain date if they were found to be in breach of any policies, MF or otherwise. The idea is you don't want to inconvenience any mozilla users with existing certificates, but what about putting CAs on notice that until XYZ criteria is rectified, they will be unable to issue further certificates until the situation is rectified. Possibly a few flaws in this idea I haven't considered, but could be a purgatory before complete removal, or just deny any future certificates... Would you really trust a Web server certificate issued by a CA that lost its accreditation or received less than an unqualified opinion on an audit? I would not, and I would be extra suspicious about server certificates issued by that CA before the negative action against it. After all, such negative action would be the result of past discrepancies by the CA, not future discrepancies. And I would certainly not trust server certificates issued after the negative action until someone -- definitely not the CA itself -- pronounced the discrepancies corrected. Then, I would trust only those server certificates issued after the corrections were determined. We are talking about MONEY and PRIVACY. How much risk are you willing to take with these? -- David E. Ross http://www.rossde.com/ I use Mozilla as my Web browser because I want a browser that complies with Web standards. See http://www.mozilla.org/. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
We are talking about MONEY and PRIVACY. How much risk are you willing to take with these? So I take it you remove a lot of certificates from your copy of Mozilla then? ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
David Ross wrote: After reviewing the discussion in this thread (and other threads), I must conclude that the whole approach to developing a policy is flawed. A policy should represent specifics based on a more general philosophy, but I don't think the philosophy itself is clear in this case. What Frank is calling the policy is, I believe, what you are calling the philosophy. Simply put, it is that the Mozilla Foundation should decide whether or not to include a CA based on a balancing of the risks and benefits of doing so. What we still need to nail down are some more specifics as to how to evaluate the benefits and risks. I believe Frank's FAQ does a reasonable job of describing how to evaluate the benefits. The risks side needs much more definition. If this chain of questions and answers is valid, then the Mozilla Foundation has an obligation to those who use its products to authenticate not only the validity of each CA certificate in the default database but also the integrity of the CA's process of issuing and signing Web server certificates with that CA certificate. I'm not sure I'd call it an obligation, but given the minimalist threat model I proposed earlier, this is something that is necessary in order to evaluate the risks. No, this does not mean only WebTrust audits. Earlier in this thread, I cited a California state regulation that specifies either WebTrust or SAS 70 audits. (See Sections 22003(a)6(C) and 22003(a)6(D) under http://www.ss.ca.gov/digsig/regulations.htm#22003.) Further, that regulation provides criteria for accepting other accreditation criteria. However, until other criteria can be clearly identified and documented, the WebTrust and SAS 70 audits are the only trustworthy and reliable bases for accepting CA certificates. WebTrust and SAS 70 audits outsource the bulk of the risk assessment. They are only useful if the threat model used for the audit is compatible with one's own threat model. It is quite possible that their threat model protects against things that Mozilla users don't care about, so requiring CAs to pass their criteria might unreasonably exclude CAs. It also might be possible and worthwhile to perform such a risk assessment without outsourcing. But we do clearly need a threat model in order to assess risks. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Ian Grigg wrote: David Ross wrote: Clearly (at least to me), the answer is: The primary and most important use of a CA certificate is to provide the Mozilla user with assurance that (1) a critical Web site is indeed what it purports to be (This is not clear at all. I think it rests on a number of false assumptions, but those are quite hard to describe in a quick email, so I'll skip that here.) As (1) is the definition of a certificate (modulo the fact that applicability goes beyond just web sites), it is as clear to me as any derivation from definitions. That you state it is not clear, omitting any argument, is in no way convincing. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposal : Installable trusted CA list
Configurability is no excuse for the lack of a good default. End users generally have no interest or competence in deciding CA trust issues. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Some interesting statistics on SSL usage in the web sphere...
I'm sure it's been posted before, however I was reading the following document (dated last march): http://iang.org/ssl/how_effective.html About how at the time there was over 9 million web servers, and only 112,000 ssl certificates, at the time only 28,000 of those were deemed valid... 28,000 out of 9,000,000... obviously host name mismatches could have also been valid but for the most part that was the case Almost 12 months later... we have almost 41,500 valid, out of 13,686,927... total of 162,000 SSL servers... ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
