Re: Possible way to increase Security
Whay don't you use LDAPv3 as protocol? This makes it easy to set up query limits, slave servers and so on. This could act as a address book also. Try www.OpenLDAP.org. The code in mozilla is mostly there, I belive. Maybe there is some issues with LDAPv3 och getting the cert. - Emil Assarsson Duane wrote: I'm currently drawing up a proposal for an independent submission for an Internet Draft and I'm after feed back on this. My idea is pretty simple, if all you have is an email address of the person you want to email, and they have a public certificate listed in the system, client software should be automatically be able to retrieve the certificate and encrypt email to the person without any intervention from the user. This would be particularly useful for web mail services and 802.1x key handling, as all you need is the email address, not a bunch of certificates. The currently level and ease of use of cryptography is pretty poor, and perhaps that's understating it somewhat, to address this I started thinking about a whois type service to distribute certificates, and it ended up somewhere a cross between a finger service and a PGP Key Exchange. Basically you connect to a tcp port on a CA service that interacts with a database, you supply an email address or a host name and the system replies with the current valid certificate which can then be used to encrypt data. For the full draft + example daemon code to achieve this go to: http://www.cacert.org/index.php?id=26prob=8 ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Possible way to increase Security
Emil Assarsson wrote: Whay don't you use LDAPv3 as protocol? This makes it easy to set up query limits, slave servers and so on. This could act as a address book also. Try www.OpenLDAP.org. The code in mozilla is mostly there, I belive. Maybe there is some issues with LDAPv3 och getting the cert. I thought about using LDAP, however my thinking on this is something extremely dumb so all any client needs to interface with it is a tcp connection, making things simpler then needing all the overhead of LDAP, dealing with LDAP libs and all the rest of it. There are a number of projects I know of that are non-email related that don't have a need for LDAP, so just a quick finger [EMAIL PROTECTED]@cacert.org would be a lot easier for them then going to all the added trouble... The initial daemon is just an interface not the database itself, the assumption here is most CAs already run a database to track certificates they've issued but there is no simple/dumb interface for machines to interface with it. -- 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 CA certificate metapolicy - 7. threat models
Julien Pierre wrote: [...] My experience is that's more protection than is afforded to credit cards in France. In particular, the quality of goods provision means that most US merchants have flexible return policies. I have tried returning stuff I bought that I was unhappy with in France (with a credit card). No luck : it's up to the merchant, there is no law that gives this right. [...] If this were a distance purchase, you have every right to return within 7 days : http://www.legifrance.gouv.fr/WAspad/RechercheSimpleArticleCode?code=CCONSOML.rcvart=L121-16 http://www.legifrance.gouv.fr/WAspad/RechercheSimpleArticleCode?code=CCONSOML.rcvart=L121-20 But not for brick and mortar commerce, it is indeed up to the merchant if you realize after purchase the product is not suited for your need and no replacement can solve the problem. Still Visa Gold and some other equivalent cards include a usually very little known and used, but still amazingly powerful insurance that enables you to get a full reimbursement if you're not satisfied with a purchase you made with the card. Anyway, this is drifting somewhat off-topic from the fraud subject. [...] Certainly :-) ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Julien Pierre wrote: [...] I guess I am the only one in the world who has that option turned on, the dialog does come up for every one of my google search and other posts. And I know to watch for it when I submit sensitive data. It has come up on a few occasions. In Mozilla, the dialog is on by default. [...]. Perhaps we should have another dialog explaining to the user in plain english but with more detail what they are really doing by disabling this option, with a second confirmation dialog. It should stay enabled. Nope. We need a better, less intrusive solution in terme of GUI. This one will always be disabled by users in 99% of cases and saying they're stupid will not change that. A really working system can only be an advance warning it seems. The lock icon is probably in the right direction to do this, but is unfortunately completely inedequate (it doesn't tell you at all if the form will go to an encrypted page). Maybe we need a lock inside the form entry ? With a different visual aspect based on the level of security ? But then we'd need a way to forbid a page to simulate the same behaviour using dynamic html. Maybe the trick would be instead to use a visual warning the form is unsafe, it would be a lot easier to make sure this warning can not be removed by dynamic html. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Jean-Marc Desperrier wrote: Maybe the trick would be instead to use a visual warning the form is unsafe, it would be a lot easier to make sure this warning can not be removed by dynamic html. Make things too annoying and web masters will promote another product and users will do likewise. Again making things too secure will only make people look for an easier way out. -- 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
Julien Pierre wrote: Jean-Marc Desperrier wrote: You mean a bank *operating* in France, Julien ? If that's so, that's a disgusting thing to do. You can call any consumers' association and denounce that. If your bank really did that, they lied and cheated you. Yes they did ... Maybe *this* is where french consumers are less protected than american. An american company would never dare do such a thing, but french companies estimate there's litle risk of being catched and even if they are they'll get way by saying oh, sorry, the clerk wasn't correctly informed, and nothing actually bad will happen to them. ___ 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: You can however implement what you want without NSS changes, by wrapping the NSS certificate verification function. By effectively reimplementing a certificate chain build algorithm. Your algorithm is simple, because it handles only simple cases, but full implementation of rfc3280, cross-certification, policy constraints, handling cert renewal where the old CA cert is signed by the new cert makes this more complex. I'd prefer to create a patch for NSS where : - we can have an optionnal maximal age paramater for revocation information - we can optionnally store a list of the CA up to the root with the revocation information for each of them. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Mozilla trunk and NSS trunk
Nelson Bolyard wrote: [...] When a new mozilla branch is created, it is a simple thing to create a branch of NSS with the same same as the mozilla branch (that is, to make NSS part of that new mozilla branch), and to make the NSS branch occur at the then-current setting of NSS_CLIENT_TAG. [...] Right. If the moz browser folks are doing things right, they will ensure that 1.7b is built from an NSS tag other than NSS_CLIENT_TAG. [...] Jean-Marc Desperrier wrote: [...] Or does this mean that the NSS trunk is inside the nightlies for testing purpose, but that there will be a roll-back to the latest stable NSS release, when Mozilla 1.7 is released ? mozilla nightlies build from a recent snapshot of the NSS trunk. When a moz release is done, NSS typically rolls forward to a new point release, rather than rolling back. OK. I think I understand now better, but there one point still strange. Everytime the Mozilla trunk branches, a new NSS branch has is created that reflects the state of NSS_CLIENT_TAG at the time of branching, and the Mozilla branch relies on that branch from then. From your description, I deduce that this branch is *not* a NSS minor release, but a branch dedicated to Mozilla. How is it possible to create later a clear reference to what version of NSS that version of Mozilla includes ? Does this mean you have to create a point release inside that branch, and not from the NSS branch that was created together with the minor release ? That would be really strange. So the NSS included inside Mozilla does *not* exactly correspond to any normal release of NSS ? As Mozilla 1.7a was created after the NSS_CLIENT_TAG that includes the bug 53133 fix, it automatically include that fix. This now appears completely unrelated to the creation of NSS 3.9.1 on the NSS 3.9 branch. Except if NSS 3.9.1 is created instead in the Mozilla 1.7a branch. This quite contradicts WTC's comment, so I'm not the only one having trouble following all that :-). Another impact of this : Asa says that 1.7a is not a branch, just a tag (they don't aim to correct bug specifically for 1.7a, they will branch if there a good reason, but for now try to avoid that) : http://groups.google.fr/groups?selm=c11gor%245671%40ripley.netscape.com; But if that's so, I don't see how they could change the reference out from NSS_CLIENT_TAG to something stable for 1.7a. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Possible way to increase Security
Duane, The idea is good, but as you point out, protocols such as LDAP already exist to do this. What's missing is a global (worldwide) directory that's independent of a particular corporation of government. The key problem is that no one entity would have the resources to host such a server. Some distribution is necessary. Your protocol proposal is overly simplistic and does not address this issue, or the missing link of where the database of certs actually comes from ... These topics have been discussed extensively on IETF pkix and smime mailing lists, but no solution was found. You should look at the archives and look for my name in there. I definitely agree with you that the need exists for a global directory that can map email address to certs. This is a gaping hole in global PKI usage. But not an easy one to solve. Duane wrote: I'm currently drawing up a proposal for an independent submission for an Internet Draft and I'm after feed back on this. My idea is pretty simple, if all you have is an email address of the person you want to email, and they have a public certificate listed in the system, client software should be automatically be able to retrieve the certificate and encrypt email to the person without any intervention from the user. This would be particularly useful for web mail services and 802.1x key handling, as all you need is the email address, not a bunch of certificates. The currently level and ease of use of cryptography is pretty poor, and perhaps that's understating it somewhat, to address this I started thinking about a whois type service to distribute certificates, and it ended up somewhere a cross between a finger service and a PGP Key Exchange. Basically you connect to a tcp port on a CA service that interacts with a database, you supply an email address or a host name and the system replies with the current valid certificate which can then be used to encrypt data. For the full draft + example daemon code to achieve this go to: http://www.cacert.org/index.php?id=26prob=8 ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Possible way to increase Security
Julien Pierre wrote: Duane, The idea is good, but as you point out, protocols such as LDAP already exist to do this. What's missing is a global (worldwide) directory that's independent of a particular corporation of government. The key problem is that no one entity would have the resources to host such a server. Some distribution is necessary. Your protocol proposal is overly simplistic and does not address this issue, or the missing link of where the database of certs actually comes from ... The idea is CAs already have databases, this method just provides a common interface to access the different systems with. Alternatively things could be done in a PGP Key Exchange fashion where people upload their own certificates just as you do with PGP. These topics have been discussed extensively on IETF pkix and smime mailing lists, but no solution was found. You should look at the archives and look for my name in there. I definitely agree with you that the need exists for a global directory that can map email address to certs. This is a gaping hole in global PKI usage. But not an easy one to solve. I think for the most part the PGP solution works, so maybe an extension to it, or something in parallel might work the best... -- 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 CA certificate metapolicy - 7. threat models
Hi, Jean-Marc Desperrier wrote: Julien Pierre wrote: [...] My experience is that's more protection than is afforded to credit cards in France. In particular, the quality of goods provision means that most US merchants have flexible return policies. I have tried returning stuff I bought that I was unhappy with in France (with a credit card). No luck : it's up to the merchant, there is no law that gives this right. [...] In my case it was brick and mortar. And the store wasn't willing to even exchange the item for something more suitable. The law was on their side. Still Visa Gold and some other equivalent cards include a usually very little known and used, but still amazingly powerful insurance that enables you to get a full reimbursement if you're not satisfied with a purchase you made with the card. Yes, but try actually using that insurance sometime. It typically has exclusions for foreign purchases. My US-issued platinum VISA credit card certainly did, so I was stuck with the item bought at retail in France, with no way to return or exchange it. I should have known not to buy retail. Anyway, end of this off-topic story. ___ 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, Jean-Marc Desperrier wrote: Julien Pierre wrote: You can however implement what you want without NSS changes, by wrapping the NSS certificate verification function. By effectively reimplementing a certificate chain build algorithm. Extending it is more like it, since you reuse the code that's aready there and don't reimplement all the other checks. Your algorithm is simple, because it handles only simple cases, but full implementation of rfc3280, cross-certification, policy constraints, handling cert renewal where the old CA cert is signed by the new cert makes this more complex. Cross-certification and policy constraints are explictly not supported by NSS at this time. You were only asking about a way of changing the CRL checking, and I provided you with an algorithm as a workaround. I do agree that to get to full RFC3280 compliance, the cert chain verification code in NSS needs to be rewritten. I can't predict whether that's going to happen or not. I'd prefer to create a patch for NSS where : - we can have an optionnal maximal age paramater for revocation information Again, please see bugzilla 233806 about this. - we can optionnally store a list of the CA up to the root with the revocation information for each of them. Can you detail the format of such a list that you propose ? Where would you want to store it ? In the softoken (cert db) ? ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Jean-Marc Desperrier wrote: Julien Pierre wrote: [...] I guess I am the only one in the world who has that option turned on, the dialog does come up for every one of my google search and other posts. And I know to watch for it when I submit sensitive data. It has come up on a few occasions. In Mozilla, the dialog is on by default. [...]. Perhaps we should have another dialog explaining to the user in plain english but with more detail what they are really doing by disabling this option, with a second confirmation dialog. It should stay enabled. Nope. We need a better, less intrusive solution in terme of GUI. This one will always be disabled by users in 99% of cases and saying they're stupid will not change that. A really working system can only be an advance warning it seems. The lock icon is probably in the right direction to do this, but is unfortunately completely inedequate (it doesn't tell you at all if the form will go to an encrypted page). Maybe we need a lock inside the form entry ? With a different visual aspect based on the level of security ? But then we'd need a way to forbid a page to simulate the same behaviour using dynamic html. Maybe the trick would be instead to use a visual warning the form is unsafe, it would be a lot easier to make sure this warning can not be removed by dynamic html. Ultimately what it comes down to is : we want checks and warnings if the user is entering sensitive and/or financial information, and we don't want them in other cases. There is no automatic way for the browser to distinguish the correct behavior when a user connects to a particular server. The option is currently set on a global basis. Perhaps we should have a better system of policy selection than a global preference buried in a menu. Maybe it could be a frame for the browser window : red means no insecure submission check, green means check. The user would be able to open either type of window, which would set the policy to warn for everything that happens within it. He would have the ability to start either type of window (start sensitive browser window ? start regular browser windows) or toggle the policy (strict / not strict) which would be clearly marked by the frame color. The policy could also be saved as attribute for each URL in the bookmarks file, so when you go to your bank, it can force the policy to strict (and at the same time show it with the appropriate frame color). And for thing like google you could bookmark it with the non-sensitive policy (add bookmark would save the current policy). Of course the visual indicator could be something else than the frame color ... But it needs to be prominently visible. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: JSS with smartcards? Why delete my post before?
Thanks very much for your reply. Is the reason U.S. export policy related or some other policy related? If it's not export policy related, is there any way to get some debug message output from JSS, or is there any switch or configuration option to get some message of what's wrong? Best Regards ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Could not establish an encrypted connection because certificate presented by www.redhat.com is invalid or corrupted. Error Code: -8102
Ankur Jain wrote: Hi All, I have created my own CA using BouncyCastle provider in PKCS12 format. I have signed the certificate using this CA and it works fine with IE for HTTPS communication but the same is not working with mozzila browser. Followign Alert comes up in the browser. Could not establish an encrypted connection because certificate presented by www.redhat.com http://www.redhat.com is invalid or corrupted. Error Code: -8102: Plesase What i am missing here. http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html#1038100 ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
