Re: Mozilla CA Certificate Policy - Useful?
On 12/05/2008 08:58 AM, Ian G: When I lose a key, all the old encrypted email is no longer readable ... which presumably happens when revocation happens as well. For your protection, yes. I don't know if there is even anyone working on Tbird security; Yes thing about this was that Mozilla recognised this about 1-2 years back and forked off Mozilla Messaging to deal with the overwhelming Firefox presence. speaks the wise man in the known... Although we wouldn't see much fruits from that yet (I don't know if they have done enough to mark a major release yet) Yes. Sent from Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20081204 Shredder/3.0b2pre -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
On 12/5/2008 4:08 AM, Eddy Nigg wrote [in part]: On 12/05/2008 08:58 AM, Ian G [also in part]: When I lose a key, all the old encrypted email is no longer readable ... which presumably happens when revocation happens as well. For your protection, yes. That's contrary to the way OpenPGP works. With OpenPGP, a revoked key can no longer be used to encrypt or sign. However, the private part of a revoked key can still be used to decrypt files and messages that the public part encrypted before revocation; and the public part of a revoked key can still be used to verify a signature generated by the private part before revocation. That's one reason why revoked keys are not removed from public key servers (the main reason being to let others know about the revocation). -- David E. Ross http://www.rossde.com/ Go to Mozdev at http://www.mozdev.org/ for quick access to extensions for Firefox, Thunderbird, SeaMonkey, and other Mozilla-related applications. You can access Mozdev much more quickly than you can Mozilla Add-Ons. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
Eddy Nigg wrote: On 12/05/2008 08:58 AM, Ian G: When I lose a key, all the old encrypted email is no longer readable ... which presumably happens when revocation happens as well. For your protection, yes. ??? If the private key is no longer available, yes, encrypted data technically cannot be decrypted anymore. If the public-key certificate was revoked but the accompanying private key is still available you should be able to decrypt archived S/MIME messages just like when the public-key certificate expired. But a sender MUST not use your public-key certificate anymore for generating a new encrypted S/MIME message to you and you MUST NOT use it for generating a new digital signature anymore. Just like when the public-key certificate expired. If NSS is doing it differently I'd consider this a bug. I'd appreciate if NSS developers could shed some light on this. If in doubt this should be clarified (e.g. on ietf-smime mailing list). Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
Michael Ströder wrote: Eddy Nigg wrote: On 12/05/2008 08:58 AM, Ian G: When I lose a key, all the old encrypted email is no longer readable ... which presumably happens when revocation happens as well. For your protection, yes. ??? If the private key is no longer available, yes, encrypted data technically cannot be decrypted anymore. Note the decision here to store the email in private-key encrypted form, instead of (for example) cleartext or re-encrypting it with the master password. This raises a lot of questions; why this implicit choice makes sense to a user, for example, and what happens when a key is lost: will the user ever return to using crypto ever again? If the public-key certificate was revoked but the accompanying private key is still available you should be able to decrypt archived S/MIME messages just like when the public-key certificate expired. But a sender MUST not use your public-key certificate anymore for generating a new encrypted S/MIME message to you and you MUST NOT use it for generating a new digital signature anymore. Just like when the public-key certificate expired. If NSS is doing it differently I'd consider this a bug. I'd appreciate if NSS developers could shed some light on this. If in doubt this should be clarified (e.g. on ietf-smime mailing list). Michael, just to clarify; the key that was lost was unable to export from a Tbird to another. Now, it was a bit more complicated and I couldn't figure it out; I'm not so worried about it. I then started thinking about revocation, as the official way to lose the key, and wondered if revocation would kill the encrypted email. But I wasn't able to figure out -- quickly -- just how Tbird deals with revocation. All of which is meant to indicate that I haven't clarified the bug to file as yet; it is worryingly brittle, but it may be doing the right thing and I may be doing the wrong thing. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
Ian G wrote: Michael Ströder wrote: Eddy Nigg wrote: On 12/05/2008 08:58 AM, Ian G: When I lose a key, all the old encrypted email is no longer readable ... which presumably happens when revocation happens as well. For your protection, yes. ??? If the private key is no longer available, yes, encrypted data technically cannot be decrypted anymore. Note the decision here to store the email in private-key encrypted form, instead of (for example) cleartext or re-encrypting it with the master password. I think it's the right behaviour to store it with the key used to decrypt the message. Note that this key is not necessarily in the key3.db. It could be on a smartcard for which key recovery is enabled in the CA backend. Also note that you might have also lost your master password. There are also S/MIME-enabled MUAs which have another local storage policy. AFAIK the S/MIME standard does not mandate any policy for local storage of encrypted e-mail. This raises a lot of questions; why this implicit choice makes sense to a user, for example, and what happens when a key is lost: will the user ever return to using crypto ever again? If your MUA stores encrypted e-mail as is (like I prefer) you have to preserve the key history. That's not news and one can deal with it easily as discussed in my other postings. I concur that a profile backup/restore facility would be admirable for Mozilla products. I then started thinking about revocation, as the official way to lose the key, You don't loose your private key if the accompanying public-key cert was revoked and AFAIK it's not forbidden by any standard to use it to decrypt archived data. Only the validity status of the public-key cert is changed. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
Ian G wrote, On 2008-12-04 22:58: (I discovered some other oddities about S/MIME recently: revocation seems to be incongruent with key distribution. I can distribute a new cert only in an S/MIME signed email, but I can't distro any updates to my key situation. When I lose a key, all the old encrypted email is no longer readable Well, of course, without the private key, you cannot decrypt. ... which presumably happens when revocation happens as well. As long as you have the private key, you can decrypt. Why would you presume otherwise? I wonder if it denies the signatures as well? Does this mean digital signing just disappeared because of a key compromise?) Revocation information includes a revocation date. After a cert has been revoked, the validity of signatures involves determining if they were made before or after the revocation date. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
Anders Rundgren wrote: Ian G wrote: Michael Ströder wrote: If the private key is no longer available, yes, encrypted data technically cannot be decrypted anymore. Note the decision here to store the email in private-key encrypted form, instead of (for example) cleartext or re-encrypting it with the master password. Yes, this is one of the weird things with S/MIME. You really wanted to encrypt the message during *transport* but as a bonus got it encrypted for *storage* as well. Personally I also prefer the MUA to do the latter. As practice showed I can keep my key history since 10 years now without any hassle (in my Linux home directory). There are S/MIME-enabled MUAs which implement local storage differently though. That's what I mean with fundamentally broken architecture. Sorry, but this whole S/MIME bashing discussion leads me to think that the main fundamentally broken thing regarding S/MIME is the lack of practice of some of its critics. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
Eddy Nigg wrote: On 12/02/2008 11:24 PM, Ian G: Liability: this is a huge issue that all should look towards. CAs set liability to zero, approximately, in general. Mozilla should do the same. Once this is done, it removes a false barrier that we keep tripping over; and we can better add value once it is gone. Ian, keep saying that there is no liability doesn't makes it the truth. I never said there was no liability! I said they set the liability to zero. There is a bit of a difference, and these differences matter. (Actually, you are right, I should be more careful. The full claim I make is that the CAs set their _expected liability_ to zero, which more clearly makes the point that there is what we could call residual liability or undisclaimable liability.) There is liability in various ways being it by law and otherwise. Even Mozilla has a liability even if it declines it. Gross negligence and other intend are pursuable always. Corporations protect themselves for such events of failures, including CAs. Yes, indeed. Your intentions are rather obvious! But I have no intention discussing them right now, I'll do that in due time should arise the need for it. Just stop beating this drum - there is no false barrier, but perhaps a barrier affecting your doings elsewhere! Denying it doesn't make it go away... Please present your alternate theory! Here is my theory: CAs set the expected liability to zero (see above caveat.) They do this by a number of techniques, which are sometimes documented and sometimes not. Proof: * liability discussions in the EV guidelines. * RPAs for most CAs Assuming that as the general rule, and recalling that the browsers are the one who have a contractual or agreement-based relationship with the users, the browsers are the ones who would be the first port of call for any claims. Now, Mozilla already disclaims its general liability, to zero, in its agreement, from what I recall. The issue is that it doesn't explicitly state that for certs. It should, IMO, to defend itself, and to present to the users a fair and accurate story: certs may help you, but there is no monetary liability to be expected. (You might fairly ask whether it needs to disclaim explicitly for certs, having disclaimed for all ... that's another debate.) The benefit for all CAs is that when the user is presented a unified zero-liability-without-explicit-agreement position by the browser as well as the CA, then all can much better build their structure -- and deliver better security -- with less fear that a judge will rule them liable in a class-action case. By way of example, you probably aren't allowed to read this, and I'm probably not allowed to post this: YOU MUST READ THIS RELYING PARTY AGREEMENT (AGREEMENT) BEFORE VALIDATING A VERISIGN CERTIFICATE , USING VERISIGN'S ONLINE CERTIFICATE STATUS PROTOCOL (OCSP) SERVICES, ACCESSING OR USING A VERISIGN OR VERISIGN AFFILIATE DATABASE OF CERTIFICATE REVOCATIONS OR RELYING ON ANY VERISIGN CERTIFICATE-RELATED INFORMATION (COLLECTIVELY, VERISIGN INFORMATION”). IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT, DO NOT SUBMIT A QUERY AND DO NOT DOWNLOAD, ACCESS, OR RELY ON ANY VERISIGN INFORMATION. IN CONSIDERATION OF YOUR AGREEMENT TO THESE TERMS, YOU ARE ENTITLED TO USE VERISIGN INFORMATION AS SET FORTH HEREIN. That's so strict so as to disclaim liability. In a document, with you the user. But this clashes with the notion that Mozilla distributes the root to users! That particular issue would not be so pernickety if there was a general industry standard that there was zero liability set, generally, to the remote end-user, unless user had entered into a specific agreement. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
I'm going to step sideways a bit and try to inject an alternative point of view here. It is not my intention to insult anyone, though it is perhaps my intention to puncture a sacred cow or two. I ask that you please read this and, rather than leaping to blind defense, Any all or nothing security scheme is going to have significant resources allocated toward its attack. Furthermore, these resources cannot be guarded against, cannot be redirected, cannot be defended against. If the attacker wins against this security scheme system, there is no flexibility within which to defeat the attacker. Any incremental security scheme is going to have significantly fewer resources allocated toward its attack -- especially when any assumptions made before, during the development of the scheme, can be revisited and cause any attackers to have to change their attack methodology. This has the effect, essentially, of giving the advantage to the defender. Why should it matter if the attacker knows a way to get into the nuclear control center and pretend he's the President of the United States, if the security system for authenticating as the President at the launch facility entrance to the facility has changed so that it's no longer subject to the attack that the attacker uses to get in to take advantage of the nuclear control center launch vulnerability? Yes, there needs to be a comprehensive security policy, describing the clear benefits that Mozilla gets from it, and the clear benefits that Mozilla's users get from it, as well as the clear benefits that websites get from it. This needs to be hashed out in as open a forum as possible, and it needs to include modular access checks so that if one piece of the protocol is found to be weak (to technical attacks, to user ignorance, to third-party malice) it can be changed without introducing too many problems. (In the case of the Debian Weak Key problem, the system should have been able to automatically make its own decision -- upon update -- that the observed keys were determined to be weak, a form should have been provided under the Help menu (report this site for security evaluation, akin to report Web forgery), and we could have had a MUCH more accurate count of exactly how many people were impacted by this vulnerability directly -- in addition to the obvious Sun OpenID vulnerability.) I would envision such a policy could be designed such that each piece could be described separately: X. X.509 Certificate Check Comment: Getting to this point relies on the TLS protocol, and/or knowledge of the email user's certificate Input: X.509 certificate chain (from server), Trust Anchors embedded in client Outputs: Inference: entity named in Subject has authority to run (and, assuming appropriate control of private keys, proves that it is running) entity named in SubjectAlternativeName, and the degree of confidence in such authority (based on trust anchor which signed it, and any limitations placed on the EE certificate) Each one of the pieces of the protocol should have an input, an output, and a set of things that can be inferred from the protocol's/proof's completion. If this knowledge (from each sub-protocol) could be converted to an agnostic, generic assertion/inference language, then each piece could truly be separate from each other. Is there any literature out there to suggest that this approach has been tried? (I'm not simply asking about Mozilla attempting this, I honestly want to see if anyone has ever tried this kind of idea before, and what their results were.) I thank you for your forbearance, and your time. -Kyle H On Tue, Dec 2, 2008 at 1:24 PM, Ian G [EMAIL PROTECTED] wrote: Anders Rundgren wrote: http://www.mozilla.org/projects/security/certs/policy From what I have seen on this list there has been a lot of talk about inclusion of various CA root certificates in the Mozilla distributions. IMO, most of these CAs are insignificant except for SSL certs. Well, to some extent one could argue that the same applies for SSL certs. The original purpose of SSL certs was to encrypt credit cards, and while a fair bit of that goes on, the new use of *importance* is one where the authentication requirements are king: online payments (and banking, stock, etc). That is, phishing being a failure of authentication, not encryption, indicates that anything that might improve authentication might help phishing. Now, it could be argued that if there is a real need to provide real protection, then EV might be the direction. It is only O(1) sites. If this is indeed an argument that is accepted, it suggests a lowered bar for all the rest. As I understand it, this is Mozilla's current posture, albeit unwritten. Why? Because the vast majority of organizations (in the rare situation that they use client-side PKI), actually issue their own client-certificates. BTW, I don't see that other providers of security software are particularly
Re: Mozilla CA Certificate Policy - Useful?
On Sat, Nov 29, 2008 at 3:57 PM, Frank Hecker [EMAIL PROTECTED] wrote: Anders Rundgren wrote: From what I have seen on this list there has been a lot of talk about inclusion of various CA root certificates in the Mozilla distributions. IMO, most of these CAs are insignificant except for SSL certs. I'm not sure your intended meaning is. There is no significant use of CA-issued certificates on the public Internet other than for enabling SSL/TLS. So why is there so much bitching about S/MIME? Oh yeah, it's cuz it's supported by another Mozilla app. The primary reason CAs apply to have certificates included into NSS, and the primary reason we have a policy about this, is because CAs want their customers' SSL certificates recognized in Firefox. Then Firefox should fork its version of NSS and manage its own certificate trust list. Since there are other clients of NSS, though, NSS has taken it upon itself to manage its own trust list, on behalf of those organizations that use it, whether those organizations want to use it or not. Why? Because the vast majority of organizations (in the rare situation that they use client-side PKI), actually issue their own client-certificates. Yes, because almost all use of client certificates is in enterprise networks, not on the public Internet. Gee. Maybe it's because the public internet doesn't rely on business-flavored security. Maybe the public internet actually needs some cryptographic mechanism that doesn't have the same presuppositions (and thus the same failures). For all that Frank and Nelson seem to be worried about the user experience, they sure seem not to lobby for improvement all that much. BTW, I don't see that other providers of security software are particularly anxious extending their preconfigured trust lists. To the contrary: Microsoft has an active program evaluating and accepting new root certificates for inclusion into Windows. They do it for the same reason we do: because CAs, web site operators, and users themselves don't want to see errors occur when connecting to SSL-enabled web sites. I'll note again that I very much like Microsoft's means of adding things to the default trust list (as of Vista): MS has a certificate that's marked for trust list signing, and every trust list they send out with every update to it is signed by that key. That means that you just have to de-trust that certificate, and you suddenly don't trust the list they sent. If MS can run a CA like that, why can't Mozilla? I'd like to see Mozilla be able to rely on the technological capabilities already extant in NSS (by revoking a certificate) rather than relying on a client update to simply remove the offending bundle of bits. (That last, by the way, may actually stymie law enforcement, by violating the forensic boundary.) -Kyle H ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
Kyle Hamilton wrote: On Sat, Nov 29, 2008 at 3:57 PM, Frank Hecker [EMAIL PROTECTED] wrote: Anders Rundgren wrote: From what I have seen on this list there has been a lot of talk about inclusion of various CA root certificates in the Mozilla distributions. IMO, most of these CAs are insignificant except for SSL certs. I'm not sure your intended meaning is. There is no significant use of CA-issued certificates on the public Internet other than for enabling SSL/TLS. So why is there so much bitching about S/MIME? Oh yeah, it's cuz it's supported by another Mozilla app. Well, it has crypto built in, so presumably could be used for email. Plugins could be used as well, although the one I tried was almost as bad, it is practically unworkable if you have more than one key in your keyring, because it assumes only one key. (I discovered some other oddities about S/MIME recently: revocation seems to be incongruent with key distribution. I can distribute a new cert only in an S/MIME signed email, but I can't distro any updates to my key situation. When I lose a key, all the old encrypted email is no longer readable ... which presumably happens when revocation happens as well. I wonder if it denies the signatures as well? Does this mean digital signing just disappeared because of a key compromise?) The primary reason CAs apply to have certificates included into NSS, and the primary reason we have a policy about this, is because CAs want their customers' SSL certificates recognized in Firefox. Then Firefox should fork its version of NSS and manage its own certificate trust list. Since there are other clients of NSS, though, NSS has taken it upon itself to manage its own trust list, on behalf of those organizations that use it, whether those organizations want to use it or not. Well, ... should is a popular word :) Why? Because the vast majority of organizations (in the rare situation that they use client-side PKI), actually issue their own client-certificates. Yes, because almost all use of client certificates is in enterprise networks, not on the public Internet. Gee. Maybe it's because the public internet doesn't rely on business-flavored security. Maybe the public internet actually needs some cryptographic mechanism that doesn't have the same presuppositions (and thus the same failures). Something like that; one favourite is the business-world concept of authentication being a necessary feature, whereas in the private world, anti-authentication is often considered a necessary feature. For all that Frank and Nelson seem to be worried about the user experience, they sure seem not to lobby for improvement all that much. Oh, for this, I have to pipe in. Mozilla is like other mostly open source operations; improvements are dependent on the availability of developers, first and foremost. In the security field, most of the developers are funded by the various organisations that have an interest in this. I don't know if there is even anyone working on Tbird security; one thing about this was that Mozilla recognised this about 1-2 years back and forked off Mozilla Messaging to deal with the overwhelming Firefox presence. Although we wouldn't see much fruits from that yet (I don't know if they have done enough to mark a major release yet) I suppose a valid question would be how much of their resource/mission is pushed towards user security and/or corporate security, and how much of this is going to feed back into their sustainability goals. I'll note again that I very much like Microsoft's means of adding things to the default trust list (as of Vista): MS has a certificate that's marked for trust list signing, and every trust list they send out with every update to it is signed by that key. That means that you just have to de-trust that certificate, and you suddenly don't trust the list they sent. This might be considered a hole in the PKI armour, at the top, in a theoretical sense. However, elegance and completion should not be taken too far. If MS can run a CA like that, why can't Mozilla? I'd like to see Mozilla be able to rely on the technological capabilities already extant in NSS (by revoking a certificate) rather than relying on a client update to simply remove the offending bundle of bits. My answer: because there is no validated threat. Yet. There is no clear and present danger. And, if we were to sit down and assume a threat in that area, blocking that hole isn't likely to earn us very much, we would probably find that we were in substantially more trouble elsewhere. Which leads us to some uncomfortable directions. Architecturally, that's a rabbit hole, and I'd like to see some firmer requirements before wasting time on it. (That last, by the way, may actually stymie law enforcement, by violating the forensic boundary.) That assumes a requirement, something that I'd be loath to do, because it places
Re: Mozilla CA Certificate Policy - Useful?
Anders Rundgren wrote: http://www.mozilla.org/projects/security/certs/policy From what I have seen on this list there has been a lot of talk about inclusion of various CA root certificates in the Mozilla distributions. IMO, most of these CAs are insignificant except for SSL certs. Well, to some extent one could argue that the same applies for SSL certs. The original purpose of SSL certs was to encrypt credit cards, and while a fair bit of that goes on, the new use of *importance* is one where the authentication requirements are king: online payments (and banking, stock, etc). That is, phishing being a failure of authentication, not encryption, indicates that anything that might improve authentication might help phishing. Now, it could be argued that if there is a real need to provide real protection, then EV might be the direction. It is only O(1) sites. If this is indeed an argument that is accepted, it suggests a lowered bar for all the rest. As I understand it, this is Mozilla's current posture, albeit unwritten. Why? Because the vast majority of organizations (in the rare situation that they use client-side PKI), actually issue their own client-certificates. BTW, I don't see that other providers of security software are particularly anxious extending their preconfigured trust lists. Right, this is a challenge to the concept that all CAs are the same. Clearly they are not, but can they be made the same? Your argument would be that they are not in a client-side, geographical context. The EV argument would be that they are not, in a server-side authentication context. Some of the CAs like the recently discussed Hungarian CA also seem to be a of local interest in the same way as the 16(!) qualified certificate CAs operating in Italy. Yes. Qualified CAs do not represent a difficulty for Mozo, IMHO, as they are well regulated already (although recent discussions indicate there are clashes between PKIX and qualified approaches at the technical level). Anyway, if the goal is establishing a user/client-level CA trust list, Mozilla is not even close and that IMO makes the whole idea somewhat less powerful. What Mozilla's goals are in security is obviously a hot topic :) It doesn't matter if it is wrong, stupid, or unsecure, but for consumer authentication local / private PKIs rule, and I don't see that changing due to things like business models, liability concerns, and cultural differences. Business models: well, the best we can do here is to surface the different interests. The problem I see here is that in security, nobody speaks for the user. It is mostly corporations, speaking as if. Liability: this is a huge issue that all should look towards. CAs set liability to zero, approximately, in general. Mozilla should do the same. Once this is done, it removes a false barrier that we keep tripping over; and we can better add value once it is gone. Cultural: I agree it is a barrier. The Europeans and North Americans don't see eye-to-eye in PKI nor security. I have no easy answer to that one. All of which supports your claim that, for consumers / individuals, local / private PKIs rule. I do not intend to respond to this posting because I understand that this is a sacred cow, and I do eat meat :-) As I've written at length elsewhere, the goals in security are not aligned well with other goals in open source, open internet and peer-to-peer communications. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
On 12/02/2008 11:24 PM, Ian G: Liability: this is a huge issue that all should look towards. CAs set liability to zero, approximately, in general. Mozilla should do the same. Once this is done, it removes a false barrier that we keep tripping over; and we can better add value once it is gone. Ian, keep saying that there is no liability doesn't makes it the truth. There is liability in various ways being it by law and otherwise. Even Mozilla has a liability even if it declines it. Gross negligence and other intend are pursuable always. Corporations protect themselves for such events of failures, including CAs. Your intentions are rather obvious! But I have no intention discussing them right now, I'll do that in due time should arise the need for it. Just stop beating this drum - there is no false barrier, but perhaps a barrier affecting your doings elsewhere! Denying it doesn't make it go away... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Mozilla CA Certificate Policy - Useful?
http://www.mozilla.org/projects/security/certs/policy From what I have seen on this list there has been a lot of talk about inclusion of various CA root certificates in the Mozilla distributions. IMO, most of these CAs are insignificant except for SSL certs. Why? Because the vast majority of organizations (in the rare situation that they use client-side PKI), actually issue their own client-certificates. BTW, I don't see that other providers of security software are particularly anxious extending their preconfigured trust lists. Some of the CAs like the recently discussed Hungarian CA also seem to be a of local interest in the same way as the 16(!) qualified certificate CAs operating in Italy. Anyway, if the goal is establishing a user/client-level CA trust list, Mozilla is not even close and that IMO makes the whole idea somewhat less powerful. It doesn't matter if it is wrong, stupid, or unsecure, but for consumer authentication local / private PKIs rule, and I don't see that changing due to things like business models, liability concerns, and cultural differences. I do not intend to respond to this posting because I understand that this is a sacred cow, and I do eat meat :-) Anders ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
Anders Rundgren wrote: From what I have seen on this list there has been a lot of talk about inclusion of various CA root certificates in the Mozilla distributions. IMO, most of these CAs are insignificant except for SSL certs. I'm not sure your intended meaning is. There is no significant use of CA-issued certificates on the public Internet other than for enabling SSL/TLS. The primary reason CAs apply to have certificates included into NSS, and the primary reason we have a policy about this, is because CAs want their customers' SSL certificates recognized in Firefox. Why? Because the vast majority of organizations (in the rare situation that they use client-side PKI), actually issue their own client-certificates. Yes, because almost all use of client certificates is in enterprise networks, not on the public Internet. BTW, I don't see that other providers of security software are particularly anxious extending their preconfigured trust lists. To the contrary: Microsoft has an active program evaluating and accepting new root certificates for inclusion into Windows. They do it for the same reason we do: because CAs, web site operators, and users themselves don't want to see errors occur when connecting to SSL-enabled web sites. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
