Re: revocation of roots
Frank Hecker wrote: So personally I'd consider a 5-day timeframe reasonable, and based on past conversations with people doing update releases, I think it might be pushed down as low as 3 days. OK, seeing as 5-days this hasn't raised too many eyebrows, I've fixed up this page: https://wiki.mozilla.org/CA:Recommendations_for_Roots#Revocation_of_the_Root http://www.mozilla.org/security/announce/ Thanks, incorporated. Also note that IIRC the Firefox automated update mechanism doesn't update all users at the same time -- it's staggered a bit to avoid overwhelming the update servers. OK, note added, thanks. One question: Is there a list of NSS user applications anywhere? Incomplete is fine. Comments welcome! For me, the story seems now to be at done, documented, maintain. Interesting as the discussion has been, there appears no better way to resolve the tension between PKIX/NSS and CA needs other than by doing a manual/human/business process, so this is as good as it gets. Thanks to all. 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
Julien R Pierre - Sun Microsystems wrote: Eddy, Eddy Nigg wrote: On 10/23/2008 12:34 AM, Julien R Pierre - Sun Microsystems: ... However reality shows that it takes quite some time until a new version of NSS seeps to the application level, including with Mozilla's own products (which would be by far the fastest). I'd expect that in an emergency a new FF/TB/SM etc. version would be shipped, but for those outside of Mozilla making use of NNS it might take month, even years. If a root ended up being compromised and we heard about it, I can assure you that we would produce a new NSS release with an update root cert module with all due haste - meaning probably within a couple of business days. The NSS team always maintains at least 2 versions - a stable branch (currently 3.11.x) and current development version (currently the trunk, which is 3.12.x) FF/TB/SM are indeed often reluctant to take NSS updates when they contain functionality updates, but I'm sure that for such a major security problem they would pick up the update as soon as it's available. OK, could we speculate that Mozo apps also could turn out a security update for their products in ... say 2 business days? Or, what number? And then, we could suggest that the whole process is likely to take a week (5 business days)? This would be an important clue on the whole process, useful for planning at the CA end, and a target hint to the apps people in the event that this ever happened. Also, add the caveat that this guesstimate only applies Mozilla product, and not these: - software that uses NSS but isn't a product of Mozilla - other libraries They have to sort themselves out. Whether we can do much about the other vendors is an open question. From the business perspective, I would suggest that we try to craft a solution for Mozilla, at least, and then see what happens. One step at a time. 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
Kyle Hamilton wrote: RFC3280 has been obsoleted by RFC5280. Aside from that, though... ...did the people who created PKIX just not realize that if a non-root certificate needs the ability to be revoked, a root certificate would also? Hi Kyle, Of course it was realised, but what they did is to kick it up to the business layer to solve. All software of this nature needs to be seen in the context of libraries, applications, humans, and businesses, etc, and any one thing can be solved at multiple places and sometimes by a combination of the components working together. The other thing to realise is that the committees are generally driven by business interests. So, if they kicked this issue upstairs to the business layer, then we can be pretty sure that this was a preferred and acceptable choice for the businesses. E.g., that is how it is wanted. Import of which is that each business has to sort it out, and make sure they have a solution in place. That's where we are today, getting a solution in place for Mozo. 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 3:25 PM +0200 10/24/08, Ian G wrote: Robert Relyea wrote: The problem with this idea is that mozilla probably does not want to be in the CA business. The overhead of creating a mozilla root key in a safe and secure manner is quite involved (and more than doing a key gen on a smart card). Yes, I see that. To which I'd add, my feeling of the PKIX-layer solution is equally non-confident: adding root-revocation capability is likely to be a mess. Robert: you are already in that business by distributing trust anchors that you have (sometimes) vetted. You are a CA without signing anything, just by distributing a trust anchor repository. Ian: it is mess today, particularly with the issues of deciding which trust anchors can vouch for which sites and services. A trust anchor management protocol is probably a bit more of a mess because it is a protocol and not just a seat-of-the-pants management task as it is today, but it is also hopefully less of a mess because it can be done outside of the software update cycle. --Paul Hoffman ___ 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 wrote: At 3:25 PM +0200 10/24/08, Ian G wrote: Robert Relyea wrote: The problem with this idea is that mozilla probably does not want to be in the CA business. The overhead of creating a mozilla root key in a safe and secure manner is quite involved (and more than doing a key gen on a smart card). Yes, I see that. To which I'd add, my feeling of the PKIX-layer solution is equally non-confident: adding root-revocation capability is likely to be a mess. Robert: you are already in that business by distributing trust anchors that you have (sometimes) vetted. You are a CA without signing anything, just by distributing a trust anchor repository. Yes, but by doing so we aren't in the business of keeping secret data. Our lists are public and can be downloaded, used, modified, etc. by anyone, without providing the attacker the ability to subvert the entire system. Going to to the cross cert idea has lots of appeal to me, but the biggest down side is Mozilla would need to protect a private key to at least the level CA's in our list protect their root keys. The likelihood of Mozilla accidentally divulging that private key is much higher than the chances of one of our CA's divulging their root keys (and the solution is basically the same -- update to a new version of mozilla with a new root). That takes on a much bigger operational burden than mozilla currently has, and bigger than mozilla has to date been willing to take on. bob 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
Ian G wrote: OK, could we speculate that Mozo apps also could turn out a security update for their products in ... say 2 business days? Or, what number? And then, we could suggest that the whole process is likely to take a week (5 business days)? The Firefox team has done security updates within a timeframe of ~5 days (business or otherwise); for example, see the Quicktime-related security vulnerability that was announced on 2007/09/12 and fixed in a security update by 2007/09/18: http://www.mozilla.org/security/announce/2007/mfsa2007-28.html One major cause of delay for typical security vulnerabilities is trying to figure out a proper fix that doesn't cause other bugs (security-related or otherwise). For a root compromise the fix (i.e., removing the root or disabling the trust flags) is straightforward and so this sort of delay could presumably be less. The lower bound on response time is likely determined by the time needed to do QA on the resulting update release. So personally I'd consider a 5-day timeframe reasonable, and based on past conversations with people doing update releases, I think it might be pushed down as low as 3 days. Frank P.S. Anyone interested in the general issue of how the Mozilla project responds to vulnerabilities can consult the Mozilla security announcements database: http://www.mozilla.org/security/announce/ combined with the associated Bugzilla reports (linked to from the announcements). -- 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 wrote: So personally I'd consider a 5-day timeframe reasonable, and based on past conversations with people doing update releases, I think it might be pushed down as low as 3 days. I should clarify that this timeframe doesn't include any CA-related time prior to the Mozilla project being informed of a problem. This is just for the Mozilla fix-and-release process. Also note that IIRC the Firefox automated update mechanism doesn't update all users at the same time -- it's staggered a bit to avoid overwhelming the update servers. (I can't remember what the relevant delays are, and couldn't find this info in quick search.) So it might take a little more time until all Firefox users get the new release with the revoked root. 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
On 10/24/2008 05:07 PM, Paul Hoffman: Robert: you are already in that business by distributing trust anchors that you have (sometimes) vetted. You are a CA without signing anything, just by distributing a trust anchor repository. Kind ofMozilla doesn't certify really anything, but extends some trust (to the user). The trust thing happens here, so many times mentioned incorrectly in relation to web sites and EE certificates. Even though one can look at it as you described, I'd not state it explicitly this way - minor point however. -- 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
At 9:42 AM -0700 10/24/08, Robert Relyea wrote: Paul Hoffman wrote: Robert: you are already in that business by distributing trust anchors that you have (sometimes) vetted. You are a CA without signing anything, just by distributing a trust anchor repository. Yes, but by doing so we aren't in the business of keeping secret data. sigh Excellent point. Going to to the cross cert idea has lots of appeal to me, but the biggest down side is Mozilla would need to protect a private key to at least the level CA's in our list protect their root keys. sigh^2 The same would be true if you ran a trust anchor management protocol, which requires the manager to have a keypair for the service. That takes on a much bigger operational burden than mozilla currently has, and bigger than mozilla has to date been willing to take on. Understood. And probably right. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Ian, Ian G wrote: Is there any reason why the message cannot be delivered by the current channels? CRL, OCSP? Yes, there is one : the fact that trust anchors are specifically excluded from CRL and OCSP revocation checking in PKIX standards. In other words, no PKIX-compliant software, including but not limited to NSS, is ever going to try to look for CRLs or check OCSP revocation status for a root. Leaving aside the standards question, that is... I don't think we can leave it out . That is the core issue. Is a self-reference in a CRL or OCSP: defined? Banned? Undefined? Going to cause chaos? Undefined. (Where, Chaos is defined as making matters worse for the software that otherwise has to deal with a rogue root out in the wild serving up the devil's contract every 3rd packet to grandma...) That would completely depend on how you are making that special CRL available. Most likely, NSS/PSM, would never even obtain it, so it would not do anything at all. It would seem that, if the root list is delivered by party A, and the software is written by party A, and the revocation is distributed to software of party A, then it should all tie together. And it could - party A can deliver a revised root list. Updating software with a new root module is a lot simpler. Of course that process has its own set of security issues as well. Hey, if it's good enough for Debian ... ;) I don't have any what Debian does, but I would prefer we don't stray too much off topic. We could talk about the Mozilla clients update process, but that would deserve at least its own thread here. And I have no involvement with it, nor much of the NSS team. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Kyle, Kyle Hamilton wrote: I think we all understand that the basic concept of a root-signed self-revocation is workable, in principle, at the information level. There may be substantial implementation questions... There are those who don't think so, since the operations defined at the Root level include revoking certificates as well as derevoking certificates, via CRL. There is the matter of the scope of a CRL . You may want to read about that. See section 5 of RFC3280 . The CRL is always signed by a given CRL signer cert, which is outside of the CRL scope. There is no such thing as a suicide note in X.509 or PKIX. Indeed. And I'm not saying suicide notes are impractical - just that they aren't defined by PKIX, and we probably would not want to implement them as CRLs. At the very least they would not fit the existing definitions for CRLs. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Eddy, Eddy Nigg wrote: - software that uses NSS but isn't a product of Mozilla Those products have to figure out where they pick up NSS. Various vendors have come up with different solutions. Both Sun and Red Hat have integrated NSS into the OS, and you can get the NSS libraries automatically updated by updating the OS. Unfortunately, currently the process can take more than a couple of days at Sun after we produce them for the patches to be up in the Solaris update manager (sigh - don't get me started on that). I don't know how long it takes at Red Hat from the time they build NSS to the time customers can download these patches. How to reach them within a reasonable useful time? I guess controlling that on the software level is problematic. For one, I'd expect MS to be fastest under such circumstances - at least for those that update their OSsame for other supported operating systems (like Red Hat), but a lot slower for applications which ship the crypto library (like NSS) as part of their software. Yes, applications that bundle NSS are indeed the slowest to get the updates. Just imagine that one of the roots in NSS would have been affected by the Debian fiasco - pretty much anybody out there could have played CA...for days, maybe weeks, maybe beyond. That's scary. Indeed. That's why we try to ensure that never happens - by having strong security requirements on every root we bundle. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Julien R Pierre - Sun Microsystems wrote: How do we revoke Mozilla's root? By updating mozilla software :) Certainly not by issuing a CRL. Mozilla doesn't have the keys needed to issue a CRL to revoke any root. (CRL's must be signed by the issuer, or by an agent with the appropriate key usage which is signed by the issue. I don't think any CA would give mozilla the keys to do this, nor would mozilla want to include the root of any CA which would give them the keys). Can we eliminate the whole CA notion by just using a single sig over the list from a root ... and just deliver signed updates? We could use PKIX to authorize the roots by setting up a mozilla root, then cross signing each of the approved roots. In that case mozilla could issue a CRL to revoke a root, then it's effectively revoking an intermediate. (and revoking the base mozilla root would still have all the problems currently described, except now you have a single point of failure). The problem with this idea is that mozilla probably does not want to be in the CA business. The overhead of creating a mozilla root key in a safe and secure manner is quite involved (and more than doing a key gen on a smart card). bob 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
Julien R Pierre - Sun Microsystems wrote: If the root could revoke itself, in the case of root cert key compromise, ie. the root cert's private key becoming public, anybody could then sign revocation information for that root CA - whether to mark it revoked or unrevoked. Leaving aside the question of what the standards say for just a moment, what's wrong with that in principle? If you know a private key has been compromised, most of the time you still have the key - so why shouldn't or couldn't it be used to sign its own suicide note? Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
At 4:39 PM +0100 10/22/08, Gervase Markham wrote: Julien R Pierre - Sun Microsystems wrote: If the root could revoke itself, in the case of root cert key compromise, ie. the root cert's private key becoming public, anybody could then sign revocation information for that root CA - whether to mark it revoked or unrevoked. Leaving aside the question of what the standards say for just a moment, what's wrong with that in principle? If you know a private key has been compromised, most of the time you still have the key - so why shouldn't or couldn't it be used to sign its own suicide note? Quite right. The flip side of this is that if *anyone* other than the person who generated the key pair has they public key, they *should* sign the suicide note and distribute it because if they have it, a bad actor could have it as well. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Gervase, Gervase Markham wrote: Julien R Pierre - Sun Microsystems wrote: If the root could revoke itself, in the case of root cert key compromise, ie. the root cert's private key becoming public, anybody could then sign revocation information for that root CA - whether to mark it revoked or unrevoked. Leaving aside the question of what the standards say for just a moment, what's wrong with that in principle? If you know a private key has been compromised, most of the time you still have the key - so why shouldn't or couldn't it be used to sign its own suicide note? I don't think we can really leave the standards out of it. One of the main problems is how a client is going to read the suicide note. Not everybody is at the scene of the crime to read it. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Paul, Paul Hoffman wrote: Updating software with a new root module is a lot simpler. Of course that process has its own set of security issues as well. It also doesn't work for users who are using a different root module. Barely traceable management action != open message protocol. True. In that case the only solution is to mark the root as untrusted. Also, note that if somebody modified the trust on a root cert previously in any way, a copy of that cert and trust is made in the user's cert database. The database trust always has priority over the root module's trust. So, updating the root module alone for those users would not suffice to disable the use of that root. Resetting the trust for a root gone rogue could be accomplished in update code programmatically, however. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Eddy, Eddy Nigg wrote: Updating software with a new root module is a lot simpler. Of course that process has its own set of security issues as well. Besides that, one of the problems is, how to reach each and every software (including older or non-updated or smaller ones). I think generally, we don't try to solve security issues in older and no longer supported software. A root compromise would fall under that category. However, in this particular case, for all NSS-based software - a manual solution exists for older applications : simply mark the root as untrusted. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
On 10/23/2008 12:34 AM, Julien R Pierre - Sun Microsystems: However, in this particular case, for all NSS-based software - a manual solution exists for older applications : simply mark the root as untrusted. If they happen to hear about it. Or if they happen to use an updated NSS library. However reality shows that it takes quite some time until a new version of NSS seeps to the application level, including with Mozilla's own products (which would be by far the fastest). I'd expect that in an emergency a new FF/TB/SM etc. version would be shipped, but for those outside of Mozilla making use of NNS it might take month, even years. I've mentioned initially at this thread, that revocation of CA roots has its problems, but I haven't been able to define something better with current tools. Apparently there is a shortcoming which needs to be addressed at some point. -- 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
2008/10/22 Ian G [EMAIL PROTECTED]: Quite right. The flip side of this is that if *anyone* other than the person who generated the key pair has they public key, they *should* sign the suicide note and distribute it because if they have it, a bad actor could have it as well. I think we all understand that the basic concept of a root-signed self-revocation is workable, in principle, at the information level. There may be substantial implementation questions... There are those who don't think so, since the operations defined at the Root level include revoking certificates as well as derevoking certificates, via CRL. There is no such thing as a suicide note in X.509 or PKIX. (I was actually just thinking of this when I was trying to get a root -- not in my control -- to mark a couple of certificates as revoked due to key compromise. If there were such a thing as a suicide note, I could mark my own certificate as revoked and then submit it to the CA for additional processing [such as adding it to CRLs and OCSP responses].) Yes, they should ... But the big question is how do they actually do that and get software to take notice of that suicide note ? Is there any reason why the message cannot be delivered by the current channels? CRL, OCSP? Leaving aside the standards question, that is... CRLs are signed by the root itself. The CRL can be reissued by anyone who has the key. OCSP is usually handled by a delegated responder with its own identity binding (and its own key). OCSP should be able to handle the case of the root is compromised by responding to all certificates with serial numbers in that root's space as being invalid, key compromise. However, this relies on the ability of the OCSP responder to operate with a known-revoked certificate. Is a self-reference in a CRL or OCSP: defined? Banned? Undefined? Going to cause chaos? Self-reference in CRL isn't a singular thing. Anyone with the root key can reissue a CRL. GoodGuy issues one with the self-reference saying revoked, key compromised. BadGuy issues one with the self-reference missing, since BadGuy wants people to still trust the root. Thus, it's chaotic. OCSP I've mentioned above. (Where, Chaos is defined as making matters worse for the software that otherwise has to deal with a rogue root out in the wild serving up the devil's contract every 3rd packet to grandma...) It would seem that, if the root list is delivered by party A, and the software is written by party A, and the revocation is distributed to software of party A, then it should all tie together. (Yes there will be some issues with party B. Refer to definition of chaos.) I'd like to see Mozilla run its own CA and cross-certify its root list. That way, Mozilla would be the higher authority and could issue non-chaotic root revocations... by revoking the cross-certifications. -Kyle H ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Kyle Hamilton wrote: 2008/10/22 Ian G [EMAIL PROTECTED]: Quite right. The flip side of this is that if *anyone* other than the person who generated the key pair has they public key, they *should* sign the suicide note and distribute it because if they have it, a bad actor could have it as well. I think we all understand that the basic concept of a root-signed self-revocation is workable, in principle, at the information level. There may be substantial implementation questions... There are those who don't think so, At the level of information and in principle, and leaving standards aside, I do not see any difficulties. Then, drifting back from information principles to implementation and standards issues, there will be substantial implementation questions, such as the ones raised. However, it is important to recognise that the difficulties are found inside PKIX and x.509, not in the capabilities of computer science, crypto or networks. since the operations defined at the Root level include revoking certificates as well as derevoking certificates, via CRL. So, a need to add a new operation, being revoke self for example. There is no such thing as a suicide note in X.509 or PKIX. Adding one would be non-standard, yes. (I was actually just thinking of this when I was trying to get a root -- not in my control -- to mark a couple of certificates as revoked due to key compromise. If there were such a thing as a suicide note, I could mark my own certificate as revoked and then submit it to the CA for additional processing [such as adding it to CRLs and OCSP responses].) Indeed. But, that might be left for a later sanity check. Yes, they should ... But the big question is how do they actually do that and get software to take notice of that suicide note ? Is there any reason why the message cannot be delivered by the current channels? CRL, OCSP? Leaving aside the standards question, that is... CRLs are signed by the root itself. The CRL can be reissued by anyone who has the key. The part means that the new CRL could de-include the root, thus un-revoking it. So we would need: * a root revocation is to be cached and not replaced. Also, as CRLs should only be acquired from stated places that are listed in the certificate, there shouldn't be a danger for existing certs. OCSP is usually handled by a delegated responder with its own identity binding (and its own key). OCSP should be able to handle the case of the root is compromised by responding to all certificates with serial numbers in that root's space as being invalid, key compromise. However, this relies on the ability of the OCSP responder to operate with a known-revoked certificate. OK. It would seem to require two things: * an extra flag that says compromised because root compromised (I don't know whether OCSP has flags or not...) * a semantic leap of all certs except my own compromised (to join the other semantic leaps inherent in the root) These three things don't sound so much, but I'd like to hear what the coders say as to how worthwhile this is. It could just be more trouble than it is worth? Is a self-reference in a CRL or OCSP: defined? Banned? Undefined? Going to cause chaos? Self-reference in CRL isn't a singular thing. Anyone with the root key can reissue a CRL. GoodGuy issues one with the self-reference saying revoked, key compromised. BadGuy issues one with the self-reference missing, since BadGuy wants people to still trust the root. Thus, it's chaotic. I don't quite see that. CRLs and OCSP checks are acquired from places listed inside the certs. So the bad guy would have to compromise the delivery of certs as well as the root itself. (If that happens, it might be fairer to say that the business is taken over rather than the root compromised :) Now, one can imagine weird cyclical loops, so it would make sense of engineering to add stickiness to the CRL as suicide note. This would probably indicate a special CRL that included only one identified cert, the root, and became sticky. OCSP I've mentioned above. (Where, Chaos is defined as making matters worse for the software that otherwise has to deal with a rogue root out in the wild serving up the devil's contract every 3rd packet to grandma...) It would seem that, if the root list is delivered by party A, and the software is written by party A, and the revocation is distributed to software of party A, then it should all tie together. (Yes there will be some issues with party B. Refer to definition of chaos.) I'd like to see Mozilla run its own CA and cross-certify its root list. That way, Mozilla would be the higher authority and could issue non-chaotic root revocations... by revoking the cross-certifications. A possibility. Some thoughts: How do we revoke Mozilla's root? How does the CRL / OCSP get delivered / run? Are we now asking each certificate check to
Re: revocation of roots
Paul Hoffman wrote: If you want to to be able to revoke roots, please consider instead getting active in the current work on TAMP (trust anchor management protocol) being discussed in the PKIX WG. Thanks for the suggestion; I presume that http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-00.txt is the main document of interest? At first glance this looks interesting, though I haven't yet read it in detail. 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
At 2:02 PM + 10/21/08, Frank Hecker wrote: Paul Hoffman wrote: If you want to to be able to revoke roots, please consider instead getting active in the current work on TAMP (trust anchor management protocol) being discussed in the PKIX WG. Thanks for the suggestion; I presume that http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-00.txt is the main document of interest? Yep. A more time-invariant way to reach the draft is at: http://tools.ietf.org/html/draft-ietf-pkix-tamp There is also a requirements document that the protocol is supposed to match at: http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs At first glance this looks interesting, though I haven't yet read it in detail. The requirements document is much shorter and more digestable than the protocol itself. Again, feel free to comment on either on the PKIX WG mailing list. There appears to be a lot of interest but few commenters. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Kyle, Kyle Hamilton wrote: On Mon, Oct 20, 2008 at 5:31 PM, Julien R Pierre - Sun Microsystems [EMAIL PROTECTED] wrote: If the root could revoke itself, in the case of root cert key compromise, ie. the root cert's private key becoming public, anybody could then sign revocation information for that root CA - whether to mark it revoked or unrevoked. The revocation therefore always has to come from a higher level than the root cert iteslf. I would think that it would be easier just to say that if a root is EVER marked revoked, it should be automatically untrusted. (the 'suicide note' concept.) There is no trace of suicide note in any PKIX standard. NSS does not arbitrarily mark certificates as revoked. The database trust flags include trusted and untrusted for specific purposes, but not revoked. NSS only declares a cert as revoked if it finds evidence of it during the processing standards-compliant revocation methods such as OCSP and CRLs. I don't think root-signed CRLs would be particularly adequate to implement suicide notes because : a) there is no last CRL . A newer one can always be issued b) how can you trust the CA's key that signed the CRL if it's been compromised ? c) if the CA's key has been compromised, you would also have to deal with the potential problem of resurrection note in a CRL, where a serial number is removed from the CRL. This is against PKIX standards except if the reason code was on hold. however, a client that would only obtain the latest CRL could be unaware of the previous CRL containing a suicide note. In cases where the root is revoked for reasons other than a root CA key compromise, this method *could* work. But I still think marking the root as not trusted is more desirable. (Perhaps I'm thinking of something far too much like PGP's capability to revoke assurances on identities associated with a key, and the ability of a key to sign a revocation certificate for itself that can be propagated to the keyservers. I don't know if X.509 or the PKIX has a means of creating a separate revocation certificate which can be considered bound to the key the same way an identity can be bound.) PKIX has the concept of indirect CRLs. I'm not sure if that could be used for this case. Indirect CRLs are not mandated to be supported by PKIX implementations. The scheme does not seem particularly secure, and right now we have chosen not to implement indirect CRLs (even for libpkix). There are several solutions in the case of NSS/PSM : 1) update the root cert module to one that no longer includes those root certs 2) update the root cert module to one that includes those root certs, but has them explicitly marked untrusted 3) without updating any software, marking the compromised root cert as untrusted . This can be done manually in PSM . Another problem with X.509 is one that MS's Friendly Certificate Name concept was supposed to handle... the CA is identified by the CA's Subject Name, and authenticated with its public key. This means that it's very difficult to change the Subject name to include information like compromised and untrusted as of [date] so that people don't blithely add trust flags that have been removed by people who have more information. Why would you want to include revocation information in the subject name ? By definition revocation is separate from the certificate. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Eddy, Eddy Nigg wrote: Ian G: 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? No, because it depends on the application and library implementing it I think. Apparently it's correct for NSS. 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. That would be a benefit in case of a disaster (including key compromise - specially for the ones issuing EE certs directly from the root). Just my $0.02. If the root could revoke itself, in the case of root cert key compromise, ie. the root cert's private key becoming public, anybody could then sign revocation information for that root CA - whether to mark it revoked or unrevoked. The revocation therefore always has to come from a higher level than the root cert iteslf. There are several solutions in the case of NSS/PSM : 1) update the root cert module to one that no longer includes those root certs 2) update the root cert module to one that includes those root certs, but has them explicitly marked untrusted 3) without updating any software, marking the compromised root cert as untrusted . This can be done manually in PSM . ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Ian, Ian G wrote: 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? Roots cannot be revoked by OCSP/CRL channels. You only need to read PKIX standards (RFC3280 for one) to figure that out. Trust anchors are outside the scope of these revocation protocols. (Therefore they can only really be replaced by an adjustment to the root list?) Correct. 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? You should take that up with the IETF if you want the CRL and OCSP protocols changed to allow root revocation. IMO, the more roots we have in NSS/PSM, the greater likelihood it is that one of them will be compromised one day. We should be prepared for the eventuality and we have several means of dealing with that, which I just described in another post to Eddy. Unfortunately there is no standards-compliant way of dealing with that problem in general. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: revocation of roots
Julien R Pierre - Sun Microsystems: Eddy, Eddy Nigg wrote: That's entirely and implementation issue and design approach. No. It is also an issue of PKIX standards as well. CAs should not implement revocation mechanisms that are not standard, and expect them to be supported by general-purpose software like NSS/Mozilla. Yes correct! Perhaps I should have suggested, that it would be interesting to have such an approach working in some form because the CA could react the fastest for all applications which would implement that approach. It could be a different key under the CA control or something else as a first defense (but not on the application level like NSS). My concern is, that reaching all applications, libraries and users which don't upgrade/update regularly (if at all and very late) is very difficult to accomplish. Instead, a revocation mechanism under the CAs control (and perhaps out of reach, with special controls in place) would be more efficient. If the root could revoke itself, in the case of root cert key compromise, ie. the root cert's private key becoming public, anybody could then sign revocation information for that root CA - whether to mark it revoked or unrevoked. Correct, however the CRLDP is included in the original certificate which is embedded into the software. This information isn't going to change. It would require at least a DNS compromise on the subject BEFORE the root would be marked revoked. I guess there could be different approaches for the application in having the root revoked at the first possible opportunity. In any case, the suggested best practice is to refrain from issuing directly from the CA root and issue from intermediate CA certificates instead. Everything remains under the CA control, including revocation. Damage would be limited and controllable in such a case and that's another reason why issuing directly from CA roots is under the problematic practice charter: https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_end_entity_certificates_directly_from_roots -- 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
Julien R Pierre - Sun Microsystems: Eddy Nigg wrote: Ian G: b. Once so revoked, are all following CRLs also revoked? The CRL would have to be valid until the expiration time of the root. Remember that CRLs don't expire. The application can consider them either valid or invalid based on the certification path of the issuer of the CRL. Or until next update. It's still valid but not updated anymore. -- 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
Julien R Pierre - Sun Microsystems: Or until next update. It's still valid but not updated anymore. It still remains valid for the application to use an old CRL if it is unable to obtain newer one, whatever the reason. I think that's what I said :-) -- 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
S/MIME support in this list doesn't work. Re: revocation of roots
How come that S/MIME-signed messages are unreadable using Microsoft Mail and Outlook Express? Anders - Original Message - From: Ian G [EMAIL PROTECTED] To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org Sent: Saturday, October 18, 2008 12:49 Subject: Re: revocation of roots ___ 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: S/MIME support in this list doesn't work. Re: revocation of roots
István Zsolt BERTA: On the long run, we plan to introduce an OCSP service that is usable for the general public, i.e. that does not require authentication and works using the 'authorized responder' concept. This week we had a discussion with the National Communications Authority, we shall be able to issue OCSP responder certificates with our CAs, even with CAs that sign qualified certificates. István, I think this is really what you should do. I understand you are on the best way to have this going! -- 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
At 2:45 AM + 10/18/08, Frank Hecker wrote: 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. It doesn't have to be a CA: it has to be a trusted service of some sort. For example, see the TAMP work currently being discussed in the PKIX WG. ___ 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: 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
