Re: Should mozilla adopt a non-binary trust model for CAs?
Tim Dierks wrote: If you want to leverage CA competition, you have to offer them actual branding space: at least a name and possibly a logo which is visible next to the lock icon. There a IETF/PKIX draft for including such extensions inside CA certificates. Do you suggest the way to do that should be support for this draft ? ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: How to use a free comodo cert with AIM
Jean-Marc Desperrier wrote: 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. I agree it would be better, but I don't have time for it. I hear there are would-be mozilla contributors who are not programmers. Maybe one of them can contribute by making that html page. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Deacon, Alex wrote: VeriSign has spent a lot of time and effort recently ensuring that not only do our OCSP services work, but that they will continue to work as the load increases. Clearly there is no excuse for any CA, especially VeriSign, to have a faulty OCSP implementation...especially if they are including the AIA extensions in certs they issue. I think mozilla will turn OCSP back on by default in some forthcoming release. Maybe soon, who knows? When we first enabled OCSP, years ago, we had a lot of unexpected problems due to OCSP responders from various CAs returning no responses at all or returning false negative responses. This caused many mozilla users to feel that https had become unusable. In haste to correct this, we implemented a preference to disable OCSP entirely, and we set that preference to disable OCSP by default. (The preference may have existed before then, but we turned off OCSP then.) OCSP has remained off by default for years since then. We felt we could not re-enable it until the vast vast majority of CAs' OCSP responders all worked, since it was a global preference. If we had not been so pressed to restore https service, we might have chosen to implement an OCSP preference on a CA by CA basis, rather than as a global preference. Had we implemented it as a CA-by-CA preference, OCSP would have remained enabled for many CAs during the past few years. I feel that cert validation is a very important part of PKI, and thus would rather that it be turned on by default. I agree that CRL's in this case are not the way to go...and this is why I suggested that OCSP (and not CRL's) be the default validation mechanism. I would say mozilla does not have a default revocation mechanism now. Whether CRLs are used or not is already user controlled on a CA by CA basis, and is not used until the user enables it for a CA. OCSP is globally enabled and disabled, but when enabled, it is only used when the appropriate cert extensions are present. So, once OCSP is re-enabled by default, perhaps it will then be said that OCSP is the default revocation mechanism. I've been running with it on for quite a while now, and it seems OK to me. This seems like overkill to me. If the platform can determine the status via one of the mechanisms (or via a local cache), then there is no reason to re-ask for the same info via another mechanism. * If there is both an AIA and CDP extension, the browser must send an OCSP request first. If OCSP fails, then it should then fall back to using a CRL. I think this is fine, as long as you don't automatically hit wire to fetch a CRL if the cert indicates OCSP is available. I would still suggest that if there is no locally cached (non-expired) revocation info for a particular cert in the local caches, that OCSP be tried first...and then CRL's as a last resort only if OCSP fails. Alex, there's an important detail or two about how CRLs work in mozilla that may set your mind at rest. Mozilla NEVER fetches CRLs during the act of cert chain validation, AFAIK. Cert chain validation uses CRLs in a CRL cache, and that cache is updated based on NextUpdate dates, not based on cert chain validations. If the CRL is missing from the cache when a validation occurs, the validation doesn't trigger a fetch right then. CRLs for a CA are fetched automatically once the user primes the pump by manually downloading the first one. The user must do this via a link on a web page or a typed URL, IINM, because AFAIK, there is no button to download the first CRL. Downloaded CRLs are kept in an on-disk database, so that they do not have to be refetched every time mozilla is restarted. Once a CRL is downloaded, new CRLs are fetched as the previous CRL nears its nextUpdate date. So, CRL fetching frequency is controlled by the CA's nextUpdate period, not by frequency of chain validations. Also, after the first CRL is downloaded, a button appears in the UI that allows the user to trigger an update download ahead of the next scheduled update. This scheme allows a user to use CRLs with some CAs and not others. It was actually designed for use in servers. (NSS is used in both servers and clients, which many mozilla folks forget.) As I understand Julien's previous answer on this topic, If a mozilla user has a CRL downloaded from a CA, and turns OCSP on, and encounters a cert from that CA that specifies OCSP, then it will check the CRL, and then if the CRL check passes, it will also check OCSP. But the CRL check wastes only browser CPU/Memory cycles, because it doesn't hit the wire. Great...are there plans to cache OCSP responses? I am not presently aware of a scheduled plan to do that. I think we agree it's important for performance of both browsers and servers. But as long as OCSP remains turned off, a cache is superfluous. My memory of this stuff isn't the best, so if someone tells me I'm misstated a detail or two above, I won't be shocked. /NelsonSpeaking only for myself, not
Re: Proposed MF certificate policy and FAQ
John Gardiner Myers wrote: 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. I agree with that last sentence. Continuity of operations is primarily to keep revocation going. If revocation stops, rightful private key holders are therafter unprotected from damages due to compromised keys. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Frank Hecker wrote: David Ross wrote: #3: I indicate that a CA that fails an audit or loses accreditation should have its certificates removed and the removal should be publicized. Mozilla users should not rely on a deficient CA. Note that in practice this will be problematic, since AFAIK removing a cert from the default database affects only users who are installing Mozilla for the first time. I'll let others speak to this issue. Frank, Things work rather differently now than they did 4 years ago. The built-in list of CAs, and the built-in list of trust info is no longer stored in the cert DB. It's in a shared library that gets replaced when a new (or old) version of mozilla is installed. If users CHANGE the trust settings on a root CA, or import a new root CA and trust, the new CA and trust info goes into the cert DB. Anyway, I think it's easier to remove trust for a built-in root CA now than before. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: publish NSS on Sourceforge?
Wan-Teh Chang wrote: 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? Isn't this what http://www.mozilla.org/projects/nss/ should be? If there is some other catalog of open source software (like freshmeat.net?), we can submit an entry for NSS. Having an NSS entry in Freshmeat sounds like an excellent idea. Gerv ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Should mozilla adopt a non-binary trust model for CAs?
Jean-Marc Desperrier wrote: Tim Dierks wrote: If you want to leverage CA competition, you have to offer them actual branding space: at least a name and possibly a logo which is visible next to the lock icon. There a IETF/PKIX draft for including such extensions inside CA certificates. Do you suggest the way to do that should be support for this draft ? No, IMHO, better to identify the CA, and then look for the locally stored, Mozilla-derived package of branding materials for that CA. There is no need to extend the Cert. Mozilla would want to install with a little package of materials, indexed of the CA or the cert. It would be the Foundation's role to prepare that package, which should be easy, as the CA will do most of the work. iang ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Should mozilla adopt a non-binary trust model for CAs?
Tim Dierks wrote: 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. Yes, perfect. In the protected area of the browser display, there should be a branding area. In this area there should be icons, imagery, and anything else that could be standardized across the certs. For example, this branding area could display a simple black ADH for an anon-Diffie-Hellman connection (if it were supported, which in general it is not), and a gray bland name for a self-signed cert. CAs could then fill the box with something more exciting than these boring standard symbols. Mozilla's task would then be much simplified in just making sure that the new DodgyCA graphics collection didn't look anything like HotDangCA's collection; something that the CAs would also help with. Only when the user is presented with the different CA brands is any form of security of site identity generated, beyond the very basic encryption layer. Another really useful display in this branding area would be the number of times the cert has been seen, and recent activities (dates, etc). Also, it's much better to allow customers to determine how trustworthy a CA is than relying on / creating a dependency on the editorial judgment 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? Or, CA Y, which offers expensive certs and a strong validation process, gets sold to CA X? Fact of the matter is: trust is a profoundly personal and private matter, not a mere decision that can (or should) be made on behalf of users by the Mozilla team. Cheers, -JC! ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
John Gardiner Myers wrote: 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. Sorry, yes, I should have left that bit out. The underlying fact here is that a CA certificate carries a signature from a third party (CA) on a key for a second party (website). That's a cryptographic fact, in general, and other claims are assumptions that may or may not be founded. It's by no means definitional whether that signature delivers anything like providing assurance that a critical web site is indeed what it purports to be. The question is whether we can move from a cryptographic statement (this key signs that key) to a business statement (this site is who they say they are) with any degree of confidence. The answer to that seems to be no. Not with any confidence. Just as an example of one only amongst a long list of difficulties, the present issue is that, as no browser goes to any trouble to to separate out *which* CA made the claim, the confidence is reduced to the lowest common denominator. (There are many more issues, but that one is apropos.) iang PS: C.f, branding discussion started by Tim Dierks. AFAIK, Peter Gutmann first made the observation about one size security policy resulting in no security. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
I agree with that last sentence. Continuity of operations is primarily to keep revocation going. If revocation stops, rightful private key holders are therafter unprotected from damages due to compromised keys. Would it make sense for MF to have some assurance by the CA that the CRL would be kept running for a minimum of 12 months after, either by their own, or by a 3rd party, or even MF? ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Folks, The uniting of the business assertion with the cryptographic assertion is accomplished via 2 step process: 1. The statement from the CA on how the cryptographic assertion is made - what checks and balances, identification and authentication mechanisms are employed to assure that the details in the cryptographic assertion (e.g. name, domain ownership etc) are valid - you can get this from the Certification Practice Statement [CPS] (this is generally referenced in the certificate) 2. The audit of the CA by an independant body rating the CA on it's adherence to it's CPS - in the world of CAs we have SAS 70 and WebTrust that are prevalent, the latter seeming to gain greater emphasis of late. I seem to have read somewhere recently that Microsoft was considering requiring CAs to pass the WebTrust audit before they would allow their certs to be embedded in their browser - anyone confirm that? Regards, -Scott Ian Grigg wrote: John Gardiner Myers wrote: 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. Sorry, yes, I should have left that bit out. The underlying fact here is that a CA certificate carries a signature from a third party (CA) on a key for a second party (website). That's a cryptographic fact, in general, and other claims are assumptions that may or may not be founded. It's by no means definitional whether that signature delivers anything like providing assurance that a critical web site is indeed what it purports to be. The question is whether we can move from a cryptographic statement (this key signs that key) to a business statement (this site is who they say they are) with any degree of confidence. The answer to that seems to be no. Not with any confidence. Just as an example of one only amongst a long list of difficulties, the present issue is that, as no browser goes to any trouble to to separate out *which* CA made the claim, the confidence is reduced to the lowest common denominator. (There are many more issues, but that one is apropos.) iang PS: C.f, branding discussion started by Tim Dierks. AFAIK, Peter Gutmann first made the observation about one size security policy resulting in no security. ___ 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
RE: On turning CRL and OCSP checking on by default.
If an OCSP response has both a thisUpdate and a nextUpdate value then yes, it is a good idea. Alex -Original Message- From: Rahul Aggarwal [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 11, 2004 10:00 PM To: [EMAIL PROTECTED] Subject: RE: On turning CRL and OCSP checking on by default. There is already a local (in-memory) cache in NSS for full CRLs. There is not one yet for OCSP responses. Great...are there plans to cache OCSP responses? Is it a good idea to cache OCSP responses?? Regards Rahul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Deacon, Alex Sent: Wednesday, February 11, 2004 6:54 AM To: 'Julien Pierre'; '[EMAIL PROTECTED]' Subject: RE: On turning CRL and OCSP checking on by default. Hi Julien, -Original Message- From: Julien Pierre [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 6:02 PM To: [EMAIL PROTECTED] Subject: Re: On turning CRL and OCSP checking on by default. Alex, Deacon, Alex wrote: 1) Although the option to perform cert validation (either via OCSP or CRL) should be a user configurable option, I believe that the application should ship with this option turned ON by default. It would be nice, but I wonder how many users would complain about all the sites not working ... A lot of OCSP servers have been incorrectly (and that includes Verisign's). I think the option should be off by default for clients, certainly for CRLs, which get very large and are not suitable from most clients at low bandwidth under any circumstances. VeriSign has spent a lot of time and effort recently ensuring that not only do our OCSP services work, but that they will continue to work as the load increases. Clearly there is no excuse for any CA, especially VeriSign, to have a faulty OCSP implementation...especially if they are including the AIA extensions in certs they issue. I feel that cert validation is a very important part of PKI, and thus would rather that it be turned on by default. I agree that CRL's in this case are not the way to go...and this is why I suggested that OCSP (and not CRL's) be the default validation mechanism. 2) The decision as to what mechanism the client should use to validate a cert needs to be dictated by the CA, not the user, using the CDP and/or AIA extension. So instead of a ca-by-ca config as you describe, I would rather see something like this - * If there is only a CDP , then the browser should fetch the CRL. This could be implemented in PSM. It would have to download the CRL and import it to the local database. PSM should also take advantage of any caching HTTP headers associated with the downloaded CRL. * If there is only a AIA extension, then the browser should send an OCSP request. Currently NSS will automatically do an OCSP check if the AIA extension is present. This occurs even if the cert was checked against a CRL also. This seems like overkill to me. If the platform can determine the status via one of the mechanisms (or via a local cache), then there is no reason to re-ask for the same info via another mechanism. * If there is both an AIA and CDP extension, the browser must send an OCSP request first. If OCSP fails, then it should then fall back to using a CRL. This would require code changes to NSS. Currently the policy is to always check CRLs first (among the locally available ones in the database), then OCSP (if enabled). I think this is fine, as long as you don't automatically hit wire to fetch a CRL if the cert indicates OCSP is available. I would still suggest that if there is no locally cached (non-expired) revocation info for a particular cert in the local caches, that OCSP be tried first...and then CRL's as a last resort only if OCSP fails. 3) All CRL's and OCSP responses should be cached locally by the browser, ideally the cert/crl cache would be separate from the standard web cache (which can be flushed/turnedoff/etc) The browser should never hit the wire if it already has access to a fresh (current non-expired) CRL or OCSP response. There is already a local (in-memory) cache in NSS for full CRLs. There is not one yet for OCSP responses. Great...are there plans to cache OCSP responses? Regards, Alex ___ 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 * Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is
Re: On turning CRL and OCSP checking on by default.
Deacon, Alex wrote: If an OCSP response has both a thisUpdate and a nextUpdate value then yes, it is a good idea. The new, enhanced, internally based on CRL, Verisign OCSP responder uses that ? The old one had no nextUpdate, and a thisUpdate generated for each request, so locally caching it wasn't really adequate. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
RE: On turning CRL and OCSP checking on by default.
Hi, -Original Message- From: Jean-Marc Desperrier [mailto:[EMAIL PROTECTED] Sent: Thursday, February 12, 2004 9:16 AM To: [EMAIL PROTECTED] Subject: Re: On turning CRL and OCSP checking on by default. Deacon, Alex wrote: If an OCSP response has both a thisUpdate and a nextUpdate value then yes, it is a good idea. The new, enhanced, internally based on CRL, Verisign OCSP responder uses that ? Yes, the new responder will include a nextUpdate, however it is not based on the CRL. (i.e. there is no relationship between the OCSP response dates and the dates in the CRL.) The old one had no nextUpdate, and a thisUpdate generated for each request, so locally caching it wasn't really adequate. Correct and agreed. Alex ___ 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
Re: Proposed MF certificate policy and FAQ
Scott Rea wrote: I seem to have read somewhere recently that Microsoft was considering requiring CAs to pass the WebTrust audit before they would allow their certs to be embedded in their browser - anyone confirm that? Were you sleeping the last two/three years, or more ? :-) It must be since IE 5.5, at the last since IE 6, that CA that did not passs an audit are not present in the browser built-in list. The current news is more that XP will try to check if it's list of CA is up-to-date with the latest version on Windows Update everytime a certificate chain is verified. So update to the list, addition or removal, will be very effective very fast for all XP/CAPI users with an on-line connexion. The list is updated for older client when they start an update download from Windows. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: dbck
This tool has not worked in years, since the cert/key databases got moved to the softoken PKCS#11 module . It would be quite difficult to get it to work again. We still keep the source in the tree, but it is not buildable as you found out. Ariadne wrote: Hi, Has anyone gotten dbck to compile, whenever I tryin nss-3.9 it fails with various errors. Is it my system (gcc-3.3.1-16) or is there a prob with the library?. Some of my users are unable to export there private keys from within Netscape and I suspect the cert7/key3 are corrupt. Anyone got ideas? Thanks, Ariadne ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: dbck
Julien Pierre wrote: Ariadne wrote: Has anyone gotten dbck to compile, whenever I tryin nss-3.9 it fails with various errors. Is it my system (gcc-3.3.1-16) or is there a prob with the library?. Some of my users are unable to export there private keys from within Netscape and I suspect the cert7/key3 are corrupt. This tool has not worked in years, since the cert/key databases got moved to the softoken PKCS#11 module . It would be quite difficult to get it to work again. We still keep the source in the tree, but it is not buildable as you found out. DBCK stopped building in NSS 3.4, and since then NSS has switched from cert7.db files to cert8.db files, whose formats are somewhat different. There were a few bugs in dbck. IMO, the development on it was unfinished when it was abandoned. However, the logic in dbck is mostly right, and it could be made to build again by staticly linking with the NSS libraries rather than using the shared libraries. If you work on it and get it working again, your contribution would be most welcome, I believe. /Nelson ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Exporting private key/cert from Netscape
Ariadne wrote: Hi, (this is prob. a dumb a question but I'm a newbie) I need to migrate some users from netscape to Outlook. They have PKI certs stored in Netscape, what is the best way to export these certs using the NSS utils? Export the user's certs and private keys as PKCS 12 files, using the UI to backup the keys and certs. Then Windows will be able to import those .p12 files. .p12 files and .pfx files are essentially the same thing, and Windows imports and exports pfx files. /Nelson ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: How administrator can manage the _builtin_ certificate list
Jani Jaakkola wrote: Am I correct, if I assume that I (still) cannot manage firefox builtin certificate list without patching and recompiling the whole thing, since the certificate list is compiled in to libnss for some unknown readon? If this is so, is there some reason for this? I don't know what the capabilities and limitations of firefox's certificate manangent UI are, or whether it even has such UI. NSS provides APIs for applications to manage trust of root certs. There's no need to recompile anything to do what you want to accomplish, although recompiling is an option, and may suit your needs (whatever they are). NSS provdes a built-in list of CA certs in a single small shared library that may be compiled separately from the rest of mozilla. There's no need to pull browser source to recompile it. I am system administrator here at University of Helsinki, and I want to install our CA-certificate to the trusted list on our Linux-network. (and yes, I know how to manage per user certificate lists) Unless ALL your users are going to use mozilla-based browsers and email programs exclusively, I'd suggest you make your root CA cert available as a download, so that ALL browser/email users can download and trust it. Oh, if you're going to make your own root CA, be VERY VERY sure you don't ever re-use cert serial numbers. Even (especially!) if you reissue your root CA cert, don't reuse the serial number. If you're using OpenSSL to issue your certs, you may have to pay attention to the serial numbers being generated to avoid this. - Jan ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Frank Hecker wrote: Nelson Bolyard wrote: The built-in list of CAs, and the built-in list of trust info is no longer stored in the cert DB. It's in a shared library that gets replaced when a new (or old) version of mozilla is installed. [snip] If users CHANGE the trust settings on a root CA, or import a new root CA and trust, the new CA and trust info goes into the cert DB. So in essence a new release of Mozilla could remove or revoke CA certs on behalf of all the users who were trusting to Mozilla to do the right thing, while not affecting users who had exercised their own judgement. Prior to NSS 3.4, which was introduced into mozilla in moz 1.3 or perhaps earlier (not sure), the built-in certs and their trust info were all copied into the cert DB. So users of mozilla whose cert DBs originated before NSS 3.4 will still have a LOT of root CA certs in them. But users whose cert DBs originated in moz 1.3 or later (including N7.1 IINM), should have rather few CA certs in their cert DBs. But I guess this is not *quite* true: If a new CA cert were added and trust flags turned on, that would affect everyone who upgraded to the new version, and users who preferred to trust their own judgement on CA certs would not necessarily be alerted during the installation process or thereafter. Instead they would have to manually check the CA cert list after the upgrade (or read the release notes). Yes, this has always been true for NSS users, IINM. Frank ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Duane wrote: I agree with that last sentence. Continuity of operations is primarily to keep revocation going. If revocation stops, rightful private key holders are therafter unprotected from damages due to compromised keys. Would it make sense for MF to have some assurance by the CA that the CRL would be kept running for a minimum of 12 months after, either by their own, or by a 3rd party, or even MF? Rather than for a minimum of 12 months, I would say until the last issued EE cert expires. Then, yes, I think that makes sense. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
John Gardiner Myers wrote: 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. As you know, a certificate is a signed statement that is either true or false. If it is false, then the act of presenting it as if it were true is an act of fraud. The statement implicit in every cert has been spoken by the Cert's issuer, and is signed by the cert's issuer. An English approximation of that statement would read something like this: Here is a public key, and a collection of one or more names (which may include one or more of each of the following: - a directory name (which may include - a person's name, - names of organizations, - names of locations and states, - postal addresses, etc.) and - an email address, and/or - a server's domain name, and/or - an IP address. I (the issuer) certify that the private key that complements this public key is held by persons (or systems) rightfully identified by all these names, and that the rightful holder(s) have the right to use this public key for the following purposes: (list of purposes), from this beginning date until this ending date. That statement is essentially a binding of names to a public key. By itself, this signed statement, this certificate, *DOES NOT* provide the Mozilla user with assurance that (1) a critical Web site is indeed what it purports to be ANYONE can make a copy of that cert, and put it on their website. The mere posession of, and presentation of, that certificate provides NO assurances whatsoever that the presenting party is the party named on the certificate. ONLY the succesful demonstration, by the party presenting the certificate, that he possesses the private key that complements the public key in the cert, coupled with the validated CA signature on the cert, assures the recipient of that party presenting the cert is the named party. That succesful demonstration can take the form of a) a signature that is verifiable by the party to whom the cert is presented (the relying party), which signature incorporates information provided by the relying party, or b) the demonstrable decryption of data that was encrypted by the relying party using the public key in the cert. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On criteria for trusting public root CAs
John Gardiner Myers wrote: Trustworthiness is not a single metric. You cannot point to an entity and say they have a trustworthiness of 5 units. Trust is the granting of the ability to break one's security and is always in the context of a security model. One does not trust an entity outright, one trusts an entity to do or not do certain things. Trust is not the same of trustworthiness. You cited the classic definition of trust, and I agree with it. I also agree with your statement about the ways in whick one trusts an entity. I believe it IS possible to objectively measure a candidate's ability and willingness to perform in a way that is worthy of trust. I believe it is possible to come up with a list of criteria, against which the candidate can be measured and scored via some metrics. It is possible to produce, for such set of criteria, a minimum acceptable score. For some criteria, it may be 100%, all or nothing. For others, it may be measured in some linear or logarithmic scale, such as the number of bits in a key, and a minimum threshold of acceptance may be applied. I believe it behooves mozilla to be as objective about this process of CA candidate selection as possible. Two or more people ought to be able to take the publicly stated set of criteria and metric functions, and the set input upon which MF relies, and do the scoring themselves and come to the same conclusion as to whether the CA candidate meets the test or does not. Perhaps there will remain a FEW subjective areas, but they should not be overriding factors in the decision, IMO. It ought not be the case that only a specific individual like Frank (or you, or me) can decide. The criteria and metrics should be objective enough that many people can come to the same conclusions. So we must first determine what the relevant security model is, then consider those factors that affect a listed CA's ability to break the security model. I like that approach, and will send a separate message to follow up on that whole line of reasoning. I will call it on a crypto security model for mozilla. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
On a crypto security threat model for mozilla
John Gardiner Myers wrote: [...] we must first determine what the relevant security model is, then consider those factors that affect a listed CA's ability to break the security model. The key threat is that an attacker is able to present a cert signed (possibly indirectly) by the CA's private key and containing a fraudulent value in a field that the user of the browser relies on. Which fields those are is debatable, but the key fields are definitely the server DNS name and S/MIME email address. I have several issues with that statement of a threat model. 1. As I mentioned in another post in this group, a cert is a signed statement from a cert issuer, certifying the binding of a name or names to a public key. The statement is either true or false. if any part of it is false, then the statement is false. I would not say that the statement contains a fraudulent value. The presentation of such a false statement is (or may be) an act of fraud. 2. I would add a crucial phrase to your key threat statement. (As an aside, let's not use the word key except when describing a cryptographic key. Let's use crucial when that is what we mean.) I would restate that statement as follows: A crucial threat is that (a) an attacker is able to present, to a relying browser (or email) user, a cert, verifiably signed (possibly indirectly) by a trusted CA's private key, containing a binding of names to a public key, and (b) the attacker is able to demonstrate that he holds the private key that complements the public key in the certificate, even though he is not the rightful holder of the names in the cert, and (c) the relying browser user is unable to detect the false presentation of this cert through various channels of communication of certificate revocation information from the cert's issuer, with the result that (d) the browser/email user relies on the false presentation to his own detriment. I would add a second statement. A second crucial thread is that (a) a relying browser/email user receives a true and proper presentation of a certificate and cryptographic proof of the presenter's private key ownership, but (b) the relying user receives false information concerning the revocation of the certificate via the channels of communication of such revocation information, falsely indicating that the certificate has been revoked, with the result that (c) the relying email/browser user rejects the truely presented cert, and does not rely on the information, to the relying user's detriment. For example, the user could be harmed if he did not believe the true statement get out now, killers are coming for you because it appeared to be unverifiable due to revocation of the signer's cert. Another form of this second threat could occur when sending an encrypted email. If one cannot encrypt an outgoing message because the recipient's cert has been falsely revoked and therefore one cannot send the afore mentioned dire warning, then the would-be sender (who is relying on the recipient's cert) may be harmed by the news of the death of the recipient. Another threat would be that evaluating a cert issued by the CA could cause Mozilla to malfunction. A CA that has malfunctioning or overly fragile OCSP responders would pose such a threat. OK. Such a threat statement agrees with the view that proper operation of revocation channels, and conveyance of the correct revocation information is also a threat to the relying user. Fraudulent revocation does not obviously relate to the browser's security model. It relates to the relying user's security model. The user may be just as harmed by rejecting true information as by accepting false. Your original statement of threat model seems to speak only to falsification of information at the time of cert issuance; that is, to the issuance of a cert continaing a false binding. But clearly (e.g through key compromise) events can make the cert presentation false after the fact. The user who receives the cert presentation relies as much on the accuracy of the cert revocation information after the issuance as on the accuracy of the information placed in the cert itself. Hence both aspects of CA operation (pre and post issuance) are worthy criteria for CA selection, IMO. /Nelson ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Nelson Bolyard wrote: Rather than for a minimum of 12 months, I would say until the last issued EE cert expires. Then, yes, I think that makes sense. This would have to be a policy decision for MF I think, and if you were to require this I also think that the MF would need to decide on a term that they would be willing to pay for domains and host CRL/OCSP stuff... If a company goes bust tomorrow, I doubt there would be any funding to keep a CRL/OCSP running beyond that, and I doubt any company large or small these days is beyond that with numerous large companies suddenly going out of business owing billions... -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Nelson Bolyard wrote: John Gardiner Myers wrote: 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. As you know, a certificate is a signed statement that is either true or false. If it is false, then the act of presenting it as if it were true is an act of fraud. The statement implicit in every cert has been spoken by the Cert's issuer, and is signed by the cert's issuer. An English approximation of that statement would read something like this: Here is a public key, and a collection of one or more names (which may include one or more of each of the following: - a directory name (which may include - a person's name, - names of organizations, - names of locations and states, - postal addresses, etc.) and - an email address, and/or - a server's domain name, and/or - an IP address. I (the issuer) certify that the private key that complements this public key is held by persons (or systems) rightfully identified by all these names, and that the rightful holder(s) have the right to use this public key for the following purposes: (list of purposes), from this beginning date until this ending date. That statement is essentially a binding of names to a public key. By itself, this signed statement, this certificate, *DOES NOT* provide the Mozilla user with assurance that (1) a critical Web site is indeed what it purports to be ANYONE can make a copy of that cert, and put it on their website. The mere posession of, and presentation of, that certificate provides NO assurances whatsoever that the presenting party is the party named on the certificate. ONLY the succesful demonstration, by the party presenting the certificate, that he possesses the private key that complements the public key in the cert, coupled with the validated CA signature on the cert, assures the recipient of that party presenting the cert is the named party. That succesful demonstration can take the form of a) a signature that is verifiable by the party to whom the cert is presented (the relying party), which signature incorporates information provided by the relying party, or b) the demonstrable decryption of data that was encrypted by the relying party using the public key in the cert. The purpose of third-party audits is to provide evidence that the CA's practices include some defined level of care when using the CA certificate to sign a Web server certificate. If CA certificates are installed only when the CA has passed such an audit, then I indeed have some assurance that a critical Web site is indeed what it purports to be. That assurance is greater than if merely the CA itself said, Trust me. It is also greater than if Mozilla said, Don't worry. We know what we're doing. For protecting my bank and stock accounts and my privacy, I want to know that the CA that issued and signed my bank's or mutual fund's server certificate has itself been vetted by a professional using recognized, objective standards. -- 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: Proposal : Installable trusted CA list
John Gardiner Myers wrote: Configurability is no excuse for the lack of a good default. End users generally have no interest or competence in deciding CA trust issues. I totally agree with you on that point, John. -- Nelson B ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Jean-Marc Desperrier wrote: Julien Pierre wrote: Technically, the revocation information from CRLs does not expire. nextUpdate only means the CA should have more recent information available, not that the CRL is expired. So I don't see it as wrong to still do the OCSP check. There is no in-band mechanism other than nextUpdate to rely on to decide that a CRL is expired . Moreover, RFC 3280 says : [The client]... acquires a suitably-recent CRL and checks that the certificate serial number is not on that CRL. The meaning of suitably-recent may vary with local policy, but it usually means the most recently-issued CRL. Jean-Marc, There's a verb missing from this next sentence you wrote, and understanding that sentence depends entirely on the missing verb. Please fill in the missing verb, here | v As a general rule, it's a bad idea to something that was only reluctantly inserted as a may in a RFC. Thanks. -- Nelson B ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
