chrome://pippki/content/certManager.xul requirements
Hi Again, I've still been working on getting all the PKI functionality working inside my XulRunner 1.8 based browser in Eclipse. I came across the Chrome url: chrome://pippki/content/certManager.xul which is exactly what I wanted to manage the PKI store. Unfortunately every button works except for the Import button. i.e. I click it and nothing happens, no errors no nothing. In regular firefox/mozilla, all is good and it works as expected, but in the embedded XulRunner browser I get nothing. I've tried clicking it both when I am and am not logged into the keystore and it makes no difference. Does anyone know of any prerequisites that need to be set for this to work? Is there anyway to debug it to find out why it is failing? FYI I'm running XulRunner 1.8 /i.e. Firefox 2. In Eclipse 3.4. Thanks! Will. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
revocation of roots
Nelson Bolyard wrote: Frank Hecker wrote: However there still appears to be an open question as to whether having an AIA extension with OCSP URL in the Microsec root certificate will cause a problem with NSS. (Nelson wrote that he was going to investigate this, but I don't recall seeing a followup to this.) Sorry, I did get the answer but forgot to write it up. :-/ Although we haven't tested it with libPKIX, as far as I know, OCSP URLs in root certs will not be a problem for NSS. NSS will never check a self-issued cert for OCSP revocation. Ah, ok, excellent, that helps with the big question: Can we conclude from this that roots cannot be revoked by means of the OCSP/CRL channel? (Therefore they can only really be replaced by an adjustment to the root list?) This notion of revoking the root has been floating around for some time in various places, but never with the hard facts of whether it is possible. And -- broader question for the policy wonks as well as the coders -- are we actually happy that this is a good thing: revocation of roots is not a CRL/OCSP possibility? Should we write this up as a policy statement somewhere? Or should we treat it as a bug to be filed fixed? It would be nice to put a stake through the heart of this issue. iang smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Eddy Nigg wrote: Now IMO as the root certificate signs itself, with the same authority it should be able to revoke itself. This would result obviously in repeating the process until the root is removed and not used anymore, but it would mark the root and all certificates signed by it revoked. I'm not sure what you mean by repeating the process. How would such revocation work in practice (assuming a PKI library that did CRL checking for roots)? Would the root just sign a CRL with its own certificate's serial number on it? Presumably at that point any application retrieving such a CRL would note revocation of the root certificate, and from that point forward would refuse to recognize as valid any certificates chaining up to the root, any subsequent CRLs signed by the root, and so on. Or am I missing something? Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
Nelson Bolyard wrote: Frank Hecker wrote: * OCSP. My understanding is that the Microsec practice of having a separate root for OCSP is very problematic, particularly given the inclusion of AIA extensions with OCSP URLs in end entity certificates. As I understand it, Microsec is removing AIA extensions with OCSP URLs from end entity certificates and from intermediate CA certificates, and this should address this problem going forward. ... after some period of time has elapsed. Certainly the day after they begin to issue certs without the OCSP URL in the AIA extension, 99+% of the existing certs will still have those AIA extensions. Over time that number should decline. Please refresh my memory here: As I understand it, the basic problem was that if the Microsec root were included in Firefox (or other products) and a user surfed to an SSL/TLS-enabled site with an end entity certificate issued by Microsec (a cert with the AIA extension with the OCSP URL), then this would cause an error in Firefox 3, because Firefox 3 does OCSP checking by default and it would get what it considered to be a bad OCSP response. Do I have this right? At what point does it become appropriate to consider the problem to have abated enough to no longer be an issue? Is it when the number of remaining outstanding valid certs that bear that AIA extension is 90%? 50%? 20%? 10%? 5%? 1%? I think it is in Microsec's interest to revoke and reissue certificates for sites that encounter problems with Firefox. I would consider this problem to be effectively addressed after Microsec actively begins an initiative to work with its affected customers to get them new certificates. At that point if customers do not update their sites IMO it is their problem, not Microsec's or Mozilla's. If approved, the Microsec root would not go into Firefox 3 until late this year or early next year. So I think there is plenty of time for Microsec to put together a suitable plan for how to ease the transition for its customers and minimize any errors that might be experienced by Firefox users. Although we haven't tested it with libPKIX, as far as I know, OCSP URLs in root certs will not be a problem for NSS. NSS will never check a self-issued cert for OCSP revocation. Thanks for looking into this. My conclusion is therefore that there is no need for Microsec to reissue its root certificate, at least as far as Mozilla is concerned. However as Rob Stradling noted, I do suggest that Microsec look at what GlobalSign did with its root refresh, in case Microsec wants to do something similar in the future. (I should also note that if Microsec's current root is approved for inclusion, I would give expedited approval to any future refresh of the root, as long as nothing had changed in terms of Microsec's operations and there were no technical problems with the new root.) One final question: Does anyone know what Thunderbird 3 will be doing in terms of OCSP checks? Will this problem affect end entity certificates issued by Microsec for S/MIME use? Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Frank Hecker: I'm not sure what you mean by repeating the process. How would such revocation work in practice (assuming a PKI library that did CRL checking for roots)? Would the root just sign a CRL with its own certificate's serial number on it? Presumably at that point any application retrieving such a CRL would note revocation of the root certificate, and from that point forward would refuse to recognize as valid any certificates chaining up to the root, any subsequent CRLs signed by the root, and so on. Or am I missing something? That's entirely and implementation issue and design approach. If we assume that the root is built-in (and valid), every time a certificate issued by this root (or sub roots) is encountered, it will read the CRL and refuse to connect (or whatever). Depending on the CRL life time, I expect the application to repeat the CRL checking over and over again until the root is removed. But such an implementation may vary. However I don't want to start an endless debate about the egg-and-chicken problem here. The principal guiding my thought is, that with the same authority the root was (self)signed, it should be possible to mark the self-signed certificate invalid. -- 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: revocation of roots
Ian G wrote, On 2008-10-17 03:28: Nelson Bolyard wrote: NSS will never check a self-issued cert for OCSP revocation. To clarify, the PRESENT RELEASE of NSS will never check a self-issued cert for OCSP revocation. Future releases may do different things. Ah, ok, excellent, that helps with the big question: Can we conclude from this that roots cannot be revoked by means of the OCSP/CRL channel? In the present release, yes, we can conclude that. (Therefore they can only really be replaced by an adjustment to the root list?) The user can always add/delete certs and/or set/unset trust on certs. This notion of revoking the root has been floating around for some time in various places, but never with the hard facts of whether it is possible. It's possible, but we've chosen not to do it in NSS. And -- broader question for the policy wonks as well as the coders -- are we actually happy that this is a good thing: revocation of roots is not a CRL/OCSP possibility? Should we write this up as a policy statement somewhere? Or should we treat it as a bug to be filed fixed? A root that revokes itself invokes the liar's paradox. NSS wishes to avoid the fate of the android Norman. :) Rather than having roots be self-revoking, a somewhat better model is to have a Uber-CA service that cross certifies other root CAs and potentially revokes its own cross certifications. Some of the participants in this list have previously advocated such a model. Maybe someone will speak up. It would be nice to put a stake through the heart of this issue. I won't bring it up again if you won't. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Having read and mused on this chicken and egg problem, I see a bunch of questions here. I doubt they will all be answered, but food for thought: 1. If a root is compromised, how is it revoked and/or replaced? 2. If it is done by signing a revocation over self in CRL form, then: a. Is NSS the authority on revocation, or is the application? b. Once so revoked, are all following CRLs also revoked? c. Or, are all certificates revoked? d. Is a CA to escrow a pre-signed revocation, such as is suggested in the PGP communities? Should this be stated, demanded, hidden, ignored? 3. If not by self-signing, then: a. Is removal from the root list a revocation? Semantically, is that what removal means? b. Is there a way in the root list (code) to signal that a root is revoked (other than by a self-signed CRL of self)? E.g., by a flag or something? c. If not, how does the root list owner intend to revoke a root when it goes rogue? For example, it is discovered that Acme CA Inc. is now selling to scammers for bulk prices, or some other motive where we can conveniently agree to employ the nuclear option. d. Can Eddy send an unsigned email to Frank asking for revocation, and explain how the entire hierarchy is toast because of some disaster? e. Can anyone else? :) 4. It is also possible to ask these questions of subroots; e.g., do the CRLs of a revoked subroot now stop working, and/or, are all certificates of that revoked subroot now super-revoked ? 5. At the higher or business or liability level, some observations: a. CAs probably want some defined way to do root revocation. b. Audit criteria and practices generally require some consideration to be in place for disaster recovery, which would suggest the CA to have in place a root compromise replacement plan. c. In serious, high availability or high value industries, there would be fierce resistance to unanswered questions like this. No single points of failure, etc. d. Does Mozilla have an interest in stating some additional things here, or is it content to leave it up to general business and/or audit considerations? 6. A somewhat contrary position is that the root should never be compromised. Assuming that, one question with this position is that it is the users and subscribers who lose, presumably, so it seems troubling to set the user up that way. iang smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
At 11:13 AM -0700 10/17/08, Nelson B Bolyard wrote: A root that revokes itself invokes the liar's paradox. NSS wishes to avoid the fate of the android Norman. :) Sorry, but that's a bit too glib. A suicide note is one valid method of trust anchor management. It does not invoke the liar's paradox if the semantics of the system accounts for it. PKIX doesn't have a standardized semantic for suicide notes, but a system such as NSS could create one. And, of course, such a semantic could be added to PKIX at any time, if the PKIX WG wanted to work on it. Rather than having roots be self-revoking, a somewhat better model is to have a Uber-CA service that cross certifies other root CAs and potentially revokes its own cross certifications. Some of the participants in this list have previously advocated such a model. Maybe someone will speak up. I can speak up for it, but I am loathe to say it is better than suicide notes. Having a trusted service that manages trust anchors for users can be very helpful. A trust anchor management protocol can also handle some of the problems that people have brought up on this list, such as wanting particular trust anchors to only cover constrained subsets of the naming tree. The downside is that few users know who they would trust to do this, and there has not been a good deployed model for making money running such a system other than in enterprises where the users have no choice. Thus, we muddle along with what we have today. The advantage of suicide notes is that it can be completely clear what they mean. If you see a message whose structure is A, signed by B, never use B in any position in any validation chain ever again. That's pretty darn simple. It is also much more limited than a full-blown trust anchor management system. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Paul Hoffman: At 11:13 AM -0700 10 I can speak up for it, but I am loathe to say it is better than suicide notes. I like the phrase suicide notethat what it really is :-) Having a trusted service that manages trust anchors for users can be very helpful. NSS itself is a trust anchor, the CA certificates are signed into certdata.txt upon the request of Frank. The advantage of suicide notes is that it can be completely clear what they mean. Indeed! Even though I believe that the big software vendors would act relatively speedily upon such an event, a CRL issued by the CA is way faster. It would also reach other and smaller applications and libraries (vendors) which the CA most likely isn't able to reach in the same manner as the four or five big browser vendors. One of the problems we have with NSS is however that it doesn't care much about CRL's. Albeit an entirely different issue, but I wonder what that patent is, which is holding NSS back and I question the validity of such a patent (of CRLDP). Did anybody ever try to challenge that patent? How can embedding a URI into an X.509 extension be patented?? 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: revocation of roots
Eddy Nigg wrote: b. Is there a way in the root list (code) to signal that a root is revoked (other than by a self-signed CRL of self)? E.g., by a flag or something? Not that I'm aware of. I don't know if this is what Ian was referring to, but in theory we can leave the root certificate in NSS but set the trust flags off. This would result in rejecting any use of a certificate whose cert chain terminated in that root. Note that we've never actually done this for any root. Note also that (I think) in this case a user could manually set the flags back to allow the root to be used again. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Frank Hecker: Eddy Nigg wrote: b. Is there a way in the root list (code) to signal that a root is revoked (other than by a self-signed CRL of self)? E.g., by a flag or something? Not that I'm aware of. I don't know if this is what Ian was referring to, but in theory we can leave the root certificate in NSS but set the trust flags off. This would result in rejecting any use of a certificate whose cert chain terminated in that root. Note that we've never actually done this for any root. Oh right, I completly forgot about that. I think I was too concentrated about what the CA can do instead reading the question correctly...Ian indeed asked about NSS (he calls it root list :-) ). Note also that (I think) in this case a user could manually set the flags back to allow the root to be used again. Which isn't such a good idea. I think the only flag which should be allowed in such a case would be the email flag. But I remember from some bug that removal of the CA root nevertheless allows to read previously encrypted mail, provided the EE cert was marked accordingly. -- 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: revocation of roots
My understanding is that when one revokes a certificate, it breaks the binding of the information in the certificate from the public key contained in the certificate. The trust of the public key as a trust anchor is a separate concept from the binding of the information in the certificate. Even if an RP gets the trust anchor as part of a certificate, and decides to accept the trust anchor as a result of the information bound in that certificate, the trust anchor isn't removed. This doesn't really seem to make much sense to me, and I'd like to see the reason code be used for CA CRL inclusions. Key compromise should be a notification that the trust anchor needs to be removed from the store, but other codes exist that would allow for a follow-up CA root certificate being issued with that key (changing the name of it, for example), without that key being removed from the trust anchors list. (all 'trusted entities' should be allowed to 'terminate the trust' on their side, since if they can no longer guarantee what they're trusted for they should at least be able to tell everyone that they don't want to be trusted anymore.) -Kyle H On Fri, Oct 17, 2008 at 6:32 AM, Frank Hecker [EMAIL PROTECTED] wrote: Eddy Nigg wrote: Now IMO as the root certificate signs itself, with the same authority it should be able to revoke itself. This would result obviously in repeating the process until the root is removed and not used anymore, but it would mark the root and all certificates signed by it revoked. I'm not sure what you mean by repeating the process. How would such revocation work in practice (assuming a PKI library that did CRL checking for roots)? Would the root just sign a CRL with its own certificate's serial number on it? Presumably at that point any application retrieving such a CRL would note revocation of the root certificate, and from that point forward would refuse to recognize as valid any certificates chaining up to the root, any subsequent CRLs signed by the root, and so on. Or am I missing something? Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Frank Hecker: Yes, but as I understand it what is being discussed here is a more elaborate scheme whereby, for example, we (Mozilla) might run an actual CA just for the purpose of cross certifying the roots that we accept. Like Nelson, I can't remember who exactly was advocating this and what their arguments for this proposal were. IIRC it was Ben Buksch? Otherwise memory is failing me...it was proposed almost two years ago during the EV discussion I think. The idea was dismissed because of the burden and responsibility to run such a CA, the counter argument was, that certdata.txt has about similar requirements. The idea never got beyond that I think... The issue was with regard to the CRLDP patent held by Entrust (which inherited it from Nortel). It's a long story, but basically due to some good work by Entrust and Sun the patent is no longer an issue as far as NSS is concerned, and the NSS team is free to implement CRLDP functionality in a future NSS release. I'll let them speak to exactly what their plans are. That sounds like some great news! I just recently happened to come across a comment at Bugzilla (I think of Kathleen) where the patent issue was mentioned once again...so libpkix will have it? Nelson? -- 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
