Re: On turning CRL and OCSP checking on by default.
Nelson Bolyard wrote: I think mozilla will turn OCSP back on by default in some forthcoming release. Maybe soon, who knows? There has been discussions else where on this issue, basically at present it would be very difficult to stop any maliciously signed code from propagating unless things could be quickly nipped in the bud via OCSP, I see this reason alone as one reason why it should most definitely be turned on by default, and possibly enforce it regardless for any CAs issuing code signing certificates... -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Julien Pierre wrote: You can however implement what you want without NSS changes, by wrapping the NSS certificate verification function. By effectively reimplementing a certificate chain build algorithm. Your algorithm is simple, because it handles only simple cases, but full implementation of rfc3280, cross-certification, policy constraints, handling cert renewal where the old CA cert is signed by the new cert makes this more complex. I'd prefer to create a patch for NSS where : - we can have an optionnal maximal age paramater for revocation information - we can optionnally store a list of the CA up to the root with the revocation information for each of them. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Jean-Marc, Jean-Marc Desperrier wrote: Julien Pierre wrote: You can however implement what you want without NSS changes, by wrapping the NSS certificate verification function. By effectively reimplementing a certificate chain build algorithm. Extending it is more like it, since you reuse the code that's aready there and don't reimplement all the other checks. Your algorithm is simple, because it handles only simple cases, but full implementation of rfc3280, cross-certification, policy constraints, handling cert renewal where the old CA cert is signed by the new cert makes this more complex. Cross-certification and policy constraints are explictly not supported by NSS at this time. You were only asking about a way of changing the CRL checking, and I provided you with an algorithm as a workaround. I do agree that to get to full RFC3280 compliance, the cert chain verification code in NSS needs to be rewritten. I can't predict whether that's going to happen or not. I'd prefer to create a patch for NSS where : - we can have an optionnal maximal age paramater for revocation information Again, please see bugzilla 233806 about this. - we can optionnally store a list of the CA up to the root with the revocation information for each of them. Can you detail the format of such a list that you propose ? Where would you want to store it ? In the softoken (cert db) ? ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Jean-Marc, Jean-Marc Desperrier wrote: Julien Pierre wrote: First, let me point out that the RFC only recommends an algorithm to verify certificates and signatures on the current date, but not at dates in the past. I don't want to strech the whole discussion any longer, but if you are actually interested in that sort of things, then have a look at RFC3126, Electronic Signature Formats for long term electronic signatures. This is an informational RFC, but the ETSI TS 101 733 document it's based on is a european standard for long term signatures. Which requirements have also been included inside the XML XAdES format. Which explains why european institutions are currently investing in that format. Thanks for the reference. I am indeed interested and will be reading up on it. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Julien Pierre wrote: First, let me point out that the RFC only recommends an algorithm to verify certificates and signatures on the current date, but not at dates in the past. I don't want to strech the whole discussion any longer, but if you are actually interested in that sort of things, then have a look at RFC3126, Electronic Signature Formats for long term electronic signatures. This is an informational RFC, but the ETSI TS 101 733 document it's based on is a european standard for long term signatures. Which requirements have also been included inside the XML XAdES format. Which explains why european institutions are currently investing in that format. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
John Gardiner Myers wrote: For reasons you mention, even checking against the latest currently available CRL is at most best effort. I fully concur this is only best effort. This is BTW exactly what I wrote in my message. But it's the level of best effort that *can* be achieved. I don't get why you want to settle for a best effort that is lower than that. I think that not doing that would be what law calls gross negligence. So nextUpdate is really a minimum for the amount of time one should use cached CRLs. I can't follow your logic here. How do you go from even checking against the latest currently available CRL is not perfect to So I don't need to do it, and worse solution are OK ? Even if I wait until the traffic light is green for pedestrian, there might be a car that won't respect it, so I won't care and I'll cross at the red light ? Or more perverse : Even if I wait until the traffic light is green for cars, there might be a pedestrian that won't respect it, so I won't care and I'll cross at the red light ? Do you think that kind of reasonning is correct ? The maximum is a matter of local policy, based on a risk assessment. There's always a risk assessment that can justify anything. In 1998, when the french banks were distributing smard cards with a signature done with a 320 bit long RSA key, their risk assessment was that updating all the ATM would be extremly costly (that was very right), and that the obscurity of the system made the probability of someone discovering the key was weak and breaking it very low, so that there was no way this would cost as much as replacing all these ATM. They ended up being ridiculised, having in a hurry to costly extend the key length to a reasonnable value, and their format loosing ground in favor of the concurrent EMV card format. Anyway, what you say does not even describe the current behavior of NSS. Currently the defined maximum for NSS is *infinite*. If there's any crl available for checking, however old, the check will *never* return crl outdated. This is not configurable. This in my opinion makes the CRL checking in NSS ineffective. When the NSS chech says check OK, a user that wants to know if all CRL used in the check were really up to day, needs to reimplement almost the whole certificate chain verification to do that. This was recognised as a problem in bugzilla. And probably there's nobody available to correct that. But I can't get the logic of saying it's not a problem. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Jean-Marc Desperrier wrote: Currently the defined maximum for NSS is *infinite*. If there's any crl available for checking, however old, the check will *never* return crl outdated. This is not configurable. This in my opinion makes the CRL checking in NSS ineffective. When the NSS chech says check OK, a user that wants to know if all CRL used in the check were really up to day, needs to reimplement almost the whole certificate chain verification to do that. This was recognised as a problem in bugzilla. And probably there's nobody available to correct that. But I can't get the logic of saying it's not a problem. Indeed, this is bugzilla 233806 . And while today is my last day at AOL, I will still be working on NSS at Sun from tomorrow. I can't say what the priority of this bug will be over there, but I can tell you that there is a good chance this bug will get fixed, inside or outside my job responsibilities. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Julien Pierre wrote: Second, a certificate may be retroactively revoked, such as in the case where a private key was compromised, but the fact wasn't noticed until a week later. There are also potential delays between the time it is noticed and the time it is reported to the CA, and between the time the CA gets the report and the time it publishes a CRL with the revocation. The point is, to do a truly accurate check according to RFCs, you can only verify a signature or certificate at the current date, with the latest currently available CRL. Anything else is best effort with unspecified behavior. For reasons you mention, even checking against the latest currently available CRL is at most best effort. So nextUpdate is really a minimum for the amount of time one should use cached CRLs. The maximum is a matter of local policy, based on a risk assessment. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Nelson B wrote: Jean-Marc, There's a verb missing from this next sentence you wrote, and understanding that sentence depends entirely on the missing verb. Please fill in the missing verb, here | v As a general rule, it's a bad idea to something that was only reluctantly inserted as a may in a RFC. Sorry about my bad typing. I didn't think it was hard to guess the verb is do. Anyway, I think the really justified part of my reasonning was the part below that sentence, and that this sentence was more or less a rant, so you could have just ignored it. Why this rant ? Because it's not the first time I see a developper say hey, I won't do what is recommended in the RFC, look ! There's a may that allows me to do otherwise and it's more than a coincidence that everytime it's a bad idea to do it. My conclusion is that you should use the permittivity allowed by a RFC may only if you have very strong *local* motive to do it, and that a general use product should never do it. I also intended to add more details in a follow-up message, but I had a Mozilla crash while that follow-up was waiting. I don't know about other Mozilla user, but I can't help feeling that since Talkback builds are not available anymore, crash is slowly becoming more frequent in new builds. The two scenario I described in the treatement of CRL can be called best-effort and non-repudiation. If you try to achieve non-repudiation, you base your decision on revocation information that is more recent than the transaction. So you will have to wait at least until you have a fresher CRL available, and maybe an additional delay if you take into account the fact the user is usually allowed a given delay to report compromission to his CA. This is similar to a check deposit at your bank, where the money will not be actually available until the bank has completed full verification with the bank on which the check is drawn, which takes several days. If you respond on-line, you can not do that, and have to settle for best-effort. But best-effort means you do the best that is possible under the circumstances, and that you get the freshest CRL you know exist. And after nextUpdate, you know there exist a fresher CRL, so by not using it, you are not doing your best-effort to have up-to-date revocation information. Of course maybe the download site is off, so it's not possible at all to get that newer CRL, so using the last available one is still best-effort, but it's hard to archive the information proving that, and the CRL checking process might not have access to it at all. So if you do CRL checking at all, there are good reasons to report this check as failed if you only have access to a CRL whose nextUpdate is in the past. Except of course if you have an date argument in the check that says Check validity for *this* date and the date predates the nextUpdate of the available CRL. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Jean-Marc, Jean-Marc Desperrier wrote: So if you do CRL checking at all, there are good reasons to report this check as failed if you only have access to a CRL whose nextUpdate is in the past. Except of course if you have an date argument in the check that says Check validity for *this* date and the date predates the nextUpdate of the available CRL. First, let me point out that the RFC only recommends an algorithm to verify certificates and signatures on the current date, but not at dates in the past. Second, a certificate may be retroactively revoked, such as in the case where a private key was compromised, but the fact wasn't noticed until a week later. Thus, even if you have a CRL which nextUpdate is after the date you are trying to verify, this may not be sufficient. The latest CRL may still contain that certificate with a prior revocation date. There are even more intricate issues for certificates with retroactive start dates. This is again a case that RFCs do not preclude, and is impossible to detect, due to the lack of an issuanceDate field in the certificate. The point is, to do a truly accurate check according to RFCs, you can only verify a signature or certificate at the current date, with the latest currently available CRL. Anything else is best effort with unspecified behavior. Which NSS does try to attempt, but there is no guarantee on the results. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Deacon, Alex wrote: VeriSign has spent a lot of time and effort recently ensuring that not only do our OCSP services work, but that they will continue to work as the load increases. Clearly there is no excuse for any CA, especially VeriSign, to have a faulty OCSP implementation...especially if they are including the AIA extensions in certs they issue. I think mozilla will turn OCSP back on by default in some forthcoming release. Maybe soon, who knows? When we first enabled OCSP, years ago, we had a lot of unexpected problems due to OCSP responders from various CAs returning no responses at all or returning false negative responses. This caused many mozilla users to feel that https had become unusable. In haste to correct this, we implemented a preference to disable OCSP entirely, and we set that preference to disable OCSP by default. (The preference may have existed before then, but we turned off OCSP then.) OCSP has remained off by default for years since then. We felt we could not re-enable it until the vast vast majority of CAs' OCSP responders all worked, since it was a global preference. If we had not been so pressed to restore https service, we might have chosen to implement an OCSP preference on a CA by CA basis, rather than as a global preference. Had we implemented it as a CA-by-CA preference, OCSP would have remained enabled for many CAs during the past few years. I feel that cert validation is a very important part of PKI, and thus would rather that it be turned on by default. I agree that CRL's in this case are not the way to go...and this is why I suggested that OCSP (and not CRL's) be the default validation mechanism. I would say mozilla does not have a default revocation mechanism now. Whether CRLs are used or not is already user controlled on a CA by CA basis, and is not used until the user enables it for a CA. OCSP is globally enabled and disabled, but when enabled, it is only used when the appropriate cert extensions are present. So, once OCSP is re-enabled by default, perhaps it will then be said that OCSP is the default revocation mechanism. I've been running with it on for quite a while now, and it seems OK to me. This seems like overkill to me. If the platform can determine the status via one of the mechanisms (or via a local cache), then there is no reason to re-ask for the same info via another mechanism. * If there is both an AIA and CDP extension, the browser must send an OCSP request first. If OCSP fails, then it should then fall back to using a CRL. I think this is fine, as long as you don't automatically hit wire to fetch a CRL if the cert indicates OCSP is available. I would still suggest that if there is no locally cached (non-expired) revocation info for a particular cert in the local caches, that OCSP be tried first...and then CRL's as a last resort only if OCSP fails. Alex, there's an important detail or two about how CRLs work in mozilla that may set your mind at rest. Mozilla NEVER fetches CRLs during the act of cert chain validation, AFAIK. Cert chain validation uses CRLs in a CRL cache, and that cache is updated based on NextUpdate dates, not based on cert chain validations. If the CRL is missing from the cache when a validation occurs, the validation doesn't trigger a fetch right then. CRLs for a CA are fetched automatically once the user primes the pump by manually downloading the first one. The user must do this via a link on a web page or a typed URL, IINM, because AFAIK, there is no button to download the first CRL. Downloaded CRLs are kept in an on-disk database, so that they do not have to be refetched every time mozilla is restarted. Once a CRL is downloaded, new CRLs are fetched as the previous CRL nears its nextUpdate date. So, CRL fetching frequency is controlled by the CA's nextUpdate period, not by frequency of chain validations. Also, after the first CRL is downloaded, a button appears in the UI that allows the user to trigger an update download ahead of the next scheduled update. This scheme allows a user to use CRLs with some CAs and not others. It was actually designed for use in servers. (NSS is used in both servers and clients, which many mozilla folks forget.) As I understand Julien's previous answer on this topic, If a mozilla user has a CRL downloaded from a CA, and turns OCSP on, and encounters a cert from that CA that specifies OCSP, then it will check the CRL, and then if the CRL check passes, it will also check OCSP. But the CRL check wastes only browser CPU/Memory cycles, because it doesn't hit the wire. Great...are there plans to cache OCSP responses? I am not presently aware of a scheduled plan to do that. I think we agree it's important for performance of both browsers and servers. But as long as OCSP remains turned off, a cache is superfluous. My memory of this stuff isn't the best, so if someone tells me I'm misstated a detail or two above, I won't be shocked. /NelsonSpeaking only for myself, not
RE: On turning CRL and OCSP checking on by default.
If an OCSP response has both a thisUpdate and a nextUpdate value then yes, it is a good idea. Alex -Original Message- From: Rahul Aggarwal [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 11, 2004 10:00 PM To: [EMAIL PROTECTED] Subject: RE: On turning CRL and OCSP checking on by default. There is already a local (in-memory) cache in NSS for full CRLs. There is not one yet for OCSP responses. Great...are there plans to cache OCSP responses? Is it a good idea to cache OCSP responses?? Regards Rahul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Deacon, Alex Sent: Wednesday, February 11, 2004 6:54 AM To: 'Julien Pierre'; '[EMAIL PROTECTED]' Subject: RE: On turning CRL and OCSP checking on by default. Hi Julien, -Original Message- From: Julien Pierre [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 6:02 PM To: [EMAIL PROTECTED] Subject: Re: On turning CRL and OCSP checking on by default. Alex, Deacon, Alex wrote: 1) Although the option to perform cert validation (either via OCSP or CRL) should be a user configurable option, I believe that the application should ship with this option turned ON by default. It would be nice, but I wonder how many users would complain about all the sites not working ... A lot of OCSP servers have been incorrectly (and that includes Verisign's). I think the option should be off by default for clients, certainly for CRLs, which get very large and are not suitable from most clients at low bandwidth under any circumstances. VeriSign has spent a lot of time and effort recently ensuring that not only do our OCSP services work, but that they will continue to work as the load increases. Clearly there is no excuse for any CA, especially VeriSign, to have a faulty OCSP implementation...especially if they are including the AIA extensions in certs they issue. I feel that cert validation is a very important part of PKI, and thus would rather that it be turned on by default. I agree that CRL's in this case are not the way to go...and this is why I suggested that OCSP (and not CRL's) be the default validation mechanism. 2) The decision as to what mechanism the client should use to validate a cert needs to be dictated by the CA, not the user, using the CDP and/or AIA extension. So instead of a ca-by-ca config as you describe, I would rather see something like this - * If there is only a CDP , then the browser should fetch the CRL. This could be implemented in PSM. It would have to download the CRL and import it to the local database. PSM should also take advantage of any caching HTTP headers associated with the downloaded CRL. * If there is only a AIA extension, then the browser should send an OCSP request. Currently NSS will automatically do an OCSP check if the AIA extension is present. This occurs even if the cert was checked against a CRL also. This seems like overkill to me. If the platform can determine the status via one of the mechanisms (or via a local cache), then there is no reason to re-ask for the same info via another mechanism. * If there is both an AIA and CDP extension, the browser must send an OCSP request first. If OCSP fails, then it should then fall back to using a CRL. This would require code changes to NSS. Currently the policy is to always check CRLs first (among the locally available ones in the database), then OCSP (if enabled). I think this is fine, as long as you don't automatically hit wire to fetch a CRL if the cert indicates OCSP is available. I would still suggest that if there is no locally cached (non-expired) revocation info for a particular cert in the local caches, that OCSP be tried first...and then CRL's as a last resort only if OCSP fails. 3) All CRL's and OCSP responses should be cached locally by the browser, ideally the cert/crl cache would be separate from the standard web cache (which can be flushed/turnedoff/etc) The browser should never hit the wire if it already has access to a fresh (current non-expired) CRL or OCSP response. There is already a local (in-memory) cache in NSS for full CRLs. There is not one yet for OCSP responses. Great...are there plans to cache OCSP responses? Regards, Alex ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla- crypto ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla- crypto * Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is
Re: On turning CRL and OCSP checking on by default.
Deacon, Alex wrote: If an OCSP response has both a thisUpdate and a nextUpdate value then yes, it is a good idea. The new, enhanced, internally based on CRL, Verisign OCSP responder uses that ? The old one had no nextUpdate, and a thisUpdate generated for each request, so locally caching it wasn't really adequate. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
RE: On turning CRL and OCSP checking on by default.
Hi, -Original Message- From: Jean-Marc Desperrier [mailto:[EMAIL PROTECTED] Sent: Thursday, February 12, 2004 9:16 AM To: [EMAIL PROTECTED] Subject: Re: On turning CRL and OCSP checking on by default. Deacon, Alex wrote: If an OCSP response has both a thisUpdate and a nextUpdate value then yes, it is a good idea. The new, enhanced, internally based on CRL, Verisign OCSP responder uses that ? Yes, the new responder will include a nextUpdate, however it is not based on the CRL. (i.e. there is no relationship between the OCSP response dates and the dates in the CRL.) The old one had no nextUpdate, and a thisUpdate generated for each request, so locally caching it wasn't really adequate. Correct and agreed. Alex ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla- crypto ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Jean-Marc Desperrier wrote: Julien Pierre wrote: Technically, the revocation information from CRLs does not expire. nextUpdate only means the CA should have more recent information available, not that the CRL is expired. So I don't see it as wrong to still do the OCSP check. There is no in-band mechanism other than nextUpdate to rely on to decide that a CRL is expired . Moreover, RFC 3280 says : [The client]... acquires a suitably-recent CRL and checks that the certificate serial number is not on that CRL. The meaning of suitably-recent may vary with local policy, but it usually means the most recently-issued CRL. Jean-Marc, There's a verb missing from this next sentence you wrote, and understanding that sentence depends entirely on the missing verb. Please fill in the missing verb, here | v As a general rule, it's a bad idea to something that was only reluctantly inserted as a may in a RFC. Thanks. -- Nelson B ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Julien Pierre wrote: [...] A lot of OCSP servers have been incorrectly (and that includes Verisign's). [...] A significatn problem with Verisign is that some time ago, they were including the OCSP extension for some people who had not paid for OCSP, so the responder would refuse to tell the state of the cert. Unfortunately Mozilla would then refuse to connect to the site, which made OCSP quite unusable. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
RE: On turning CRL and OCSP checking on by default.
As I mentioned in a pervious email...this has been fixed. Alex -Original Message- From: Jean-Marc Desperrier [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 11, 2004 10:24 AM To: [EMAIL PROTECTED] Subject: Re: On turning CRL and OCSP checking on by default. Julien Pierre wrote: [...] A lot of OCSP servers have been incorrectly (and that includes Verisign's). [...] A significatn problem with Verisign is that some time ago, they were including the OCSP extension for some people who had not paid for OCSP, so the responder would refuse to tell the state of the cert. Unfortunately Mozilla would then refuse to connect to the site, which made OCSP quite unusable. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla- crypto ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
RE: On turning CRL and OCSP checking on by default.
Hi Julien, -Original Message- From: Julien Pierre [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 6:02 PM To: [EMAIL PROTECTED] Subject: Re: On turning CRL and OCSP checking on by default. Alex, Deacon, Alex wrote: 1) Although the option to perform cert validation (either via OCSP or CRL) should be a user configurable option, I believe that the application should ship with this option turned ON by default. It would be nice, but I wonder how many users would complain about all the sites not working ... A lot of OCSP servers have been incorrectly (and that includes Verisign's). I think the option should be off by default for clients, certainly for CRLs, which get very large and are not suitable from most clients at low bandwidth under any circumstances. VeriSign has spent a lot of time and effort recently ensuring that not only do our OCSP services work, but that they will continue to work as the load increases. Clearly there is no excuse for any CA, especially VeriSign, to have a faulty OCSP implementation...especially if they are including the AIA extensions in certs they issue. I feel that cert validation is a very important part of PKI, and thus would rather that it be turned on by default. I agree that CRL's in this case are not the way to go...and this is why I suggested that OCSP (and not CRL's) be the default validation mechanism. 2) The decision as to what mechanism the client should use to validate a cert needs to be dictated by the CA, not the user, using the CDP and/or AIA extension. So instead of a ca-by-ca config as you describe, I would rather see something like this - * If there is only a CDP , then the browser should fetch the CRL. This could be implemented in PSM. It would have to download the CRL and import it to the local database. PSM should also take advantage of any caching HTTP headers associated with the downloaded CRL. * If there is only a AIA extension, then the browser should send an OCSP request. Currently NSS will automatically do an OCSP check if the AIA extension is present. This occurs even if the cert was checked against a CRL also. This seems like overkill to me. If the platform can determine the status via one of the mechanisms (or via a local cache), then there is no reason to re-ask for the same info via another mechanism. * If there is both an AIA and CDP extension, the browser must send an OCSP request first. If OCSP fails, then it should then fall back to using a CRL. This would require code changes to NSS. Currently the policy is to always check CRLs first (among the locally available ones in the database), then OCSP (if enabled). I think this is fine, as long as you don't automatically hit wire to fetch a CRL if the cert indicates OCSP is available. I would still suggest that if there is no locally cached (non-expired) revocation info for a particular cert in the local caches, that OCSP be tried first...and then CRL's as a last resort only if OCSP fails. 3) All CRL's and OCSP responses should be cached locally by the browser, ideally the cert/crl cache would be separate from the standard web cache (which can be flushed/turnedoff/etc) The browser should never hit the wire if it already has access to a fresh (current non-expired) CRL or OCSP response. There is already a local (in-memory) cache in NSS for full CRLs. There is not one yet for OCSP responses. Great...are there plans to cache OCSP responses? Regards, Alex ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla- crypto ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
RE: On turning CRL and OCSP checking on by default.
Hi Duane, Agreed. If a CA indicates via an AIA that OCSP services are available then it better ensure things are working correctly. Alex -Original Message- From: Duane [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 7:41 PM To: [EMAIL PROTECTED] Subject: Re: On turning CRL and OCSP checking on by default. It would be nice, but I wonder how many users would complain about all the sites not working ... A lot of OCSP servers have been incorrectly (and that includes Verisign's). I think the option should be off by default for clients, certainly for CRLs, which get very large and are not suitable from most clients at low bandwidth under any circumstances. with OCSP, shouldn't the CAs have some quality assurance to fix these kinds of problems in a timely manner, I'm sure this is possibly under the wrong thread, but this relates back to the pre/post CA checks... or at least I percieve it to... ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla- crypto ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Hi, Deacon, Alex wrote: VeriSign has spent a lot of time and effort recently ensuring that not only do our OCSP services work, but that they will continue to work as the load increases. Clearly there is no excuse for any CA, especially VeriSign, to have a faulty OCSP implementation...especially if they are including the AIA extensions in certs they issue. I agree. I feel that cert validation is a very important part of PKI, and thus would rather that it be turned on by default. I agree that CRL's in this case are not the way to go...and this is why I suggested that OCSP (and not CRL's) be the default validation mechanism. I believe OCSP is indeed fine for clients and someday it may become the default. PSM should also take advantage of any caching HTTP headers associated with the downloaded CRL. Can you be more specific as to which headers you are referring to ? Currently NSS will automatically do an OCSP check if the AIA extension is present. This occurs even if the cert was checked against a CRL also. This seems like overkill to me. If the platform can determine the status via one of the mechanisms (or via a local cache), then there is no reason to re-ask for the same info via another mechanism. You could call it paranoid. But keep in mind that NSS is used by programs that are both servers and clients. NSS clients that need revocation can enable OCSP. Only the OCSP revocation check will be performed, in this case transparently by NSS, because the client has not explicitly downloaded the CRLs, so they are not available. NSS servers that need revocation (for client auth) have some code to download CRLs . Netscape Enterprise Server 6.1 features an in-memory PKCS#11 module (called revocator) that periodically downloads CRLs. When verifying certs, NSS automatically searches all PKCS#11 tokens for CRLs, and caches them. NSS servers don't typically enable OCSP due to the high performance cost of having one extra outgoing connection for each incoming client. So, the fact that NSS tries both CRLs and OCSP does not matter much, since usually only one is available by virtue of application configuration. I would still suggest that if there is no locally cached (non-expired) revocation info for a particular cert in the local caches, that OCSP be tried first...and then CRL's as a last resort only if OCSP fails. Technically, the revocation information from CRLs does not expire. nextUpdate only means the CA should have more recent information available, not that the CRL is expired. So I don't see it as wrong to still do the OCSP check. I understand your point about not hitting the wire if CRLs are available and have been checked - you want to reduce the load on your OCSP servers. As I said above, I just think most clients will not download CRLs due to size and the lack of browser-initiated CRL download process, and should enable OCSP as their only means of revocation. So the impact of doing this optimization in NSS on server load would be in my opinion minimal. If circumstances were to change and millions of clients started downloading CRLs, then maybe the double-check for OCSP also in NSS can be considered, but I don't see it right now. I think you'll have big server problems too if clients try to use CRLs . It's a bandwidth vs CPU trade-off. There is already a local (in-memory) cache in NSS for full CRLs. There is not one yet for OCSP responses. Great...are there plans to cache OCSP responses? The need is known, but no resources are currently assigned to this feature. It may become a priority in the feature, or not. If you want it really bad feel free to contribute the code to NSS. I can point you in the right direction, as I wrote the CRL cache and hopefully some of the code can be shared. http://bugzilla.mozilla.org/show_bug.cgi?id=48597 http://bugzilla.mozilla.org/show_bug.cgi?id=91532 http://bugzilla.mozilla.org/show_bug.cgi?id=205406 ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Turning on OCSP by default is bug 110161. The lack of an OCSP cache is one issue. A harder issue is that NSPR's nonblocking model is not capable of passing the information needed to do nonblocking OCSP queries during an SSL handshake. When I last tried turning OCSP on, Verisign had screwed up OCSP responders. Their responders would fail to respond to the OCSP queries sent by NSS. As a result, if you enabled OCSP in Mozilla, every time you did a handshake with a server using a Verisign cert, Mozilla would hang for 30 seconds, timing out on the OCSP responder. Now, Verisign has probably since fixed their OCSP responders. But the problem is that if an OCSP responder is horked, that can easily cause Mozilla to hang for 30 seconds. This is not a web site takes a long time to respond hang, this is a mozilla becomes completely nonresponsive hang. And the limitations in NSPR's IO layering APIs make this extremely difficult to fix. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
OCSP is turned off by default in mozilla, because frankly, a lot of home-grown CAs put out certs that claimed they did OCSP, when they didn't. So, mozilla would get one of their certs (e.g. from an https server), try to contact the OCSP server (and fail), and then claim the cert is revoked (the RIGHT THING to do in that circumstance), much to the browser user's dismay! While it might be the right thing to do long term, surely if it fails ignore the check took place might be the easiest approach, or perhaps, disable for a CA on failures over 10 days or something, I'm not sure, just seems to me your trying to by pass the failure when you could just ignore it instead, may not be as secure, but what you're suggesting is in the same boat anyways... ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Duane wrote: OCSP is turned off by default in mozilla, because frankly, a lot of home-grown CAs put out certs that claimed they did OCSP, when they didn't. So, mozilla would get one of their certs (e.g. from an https server), try to contact the OCSP server (and fail), and then claim the cert is revoked (the RIGHT THING to do in that circumstance), much to the browser user's dismay! While it might be the right thing to do long term, surely if it fails ignore the check took place might be the easiest approach, That approach is vulnerable to an attack. Suppose a bad guy has wrongfully obtained a copy of another user's private key. The other user has revoked his own cert, but the bad guy wants to effectively undo the revocation. So, he poisons some DNS caches, getting them to point to the wrong IP address, or takes any of a number of actions that cause OCSP requests to fail for a large number of users. If the browser silently ignores failed OCSP responses, the bad guy wins. He has rendered OCSP to be of no value. There are standards that define the behavior for these cases. Ignoring the outcome is not one of the allowed behaviors. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
RE: On turning CRL and OCSP checking on by default.
Hi Nelson, Here are my thoughts on how this should work. 1) Although the option to perform cert validation (either via OCSP or CRL) should be a user configurable option, I believe that the application should ship with this option turned ON by default. 2) The decision as to what mechanism the client should use to validate a cert needs to be dictated by the CA, not the user, using the CDP and/or AIA extension. So instead of a ca-by-ca config as you describe, I would rather see something like this - * If there is only a CDP , then the browser should fetch the CRL. * If there is only a AIA extension, then the browser should send an OCSP request. * If there is both an AIA and CDP extension, the browser must send an OCSP request first. If OCSP fails, then it should then fall back to using a CRL. 3) All CRL's and OCSP responses should be cached locally by the browser, ideally the cert/crl cache would be separate from the standard web cache (which can be flushed/turnedoff/etc) The browser should never hit the wire if it already has access to a fresh (current non-expired) CRL or OCSP response. Regards, Alex -Original Message- From: Nelson B [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 1:58 PM To: [EMAIL PROTECTED] Subject: On turning CRL and OCSP checking on by default. Mozilla supports two standard ways to retrieve information from a Certificate Authority (CA) concerning the revocation status of a certificate issued by that CA. That is, two ways to ask the server, is this cert that you issued revoked? or is it still good? The two ways are: 1. Certificate Revocation List, a signed document from the CA that lists ALL the serial numbers of ALL of the certs issued by that CA that have been revoked. This can be huge, MEGABYTES! 2. OCSP. A protocol by which the client send the issuer name and serial number of one cert to the CA, and the CA replies with a signed message saying wether that cert (alone) is revoked or not. mozilla supports both of these, but the user must takes steps to enable them. OCSP is controlled by a preference. You turn it on or off for all CAs. It is off by default, IINM. The user has to manually initiate the first CRL download from a CA. After the first CRL has been downloaded succesfully, then mozilla will ask the user if he wants it to automatically fetch future CRLs from that CA. The user only needs to check the box, and click OK. For clients (e.g. browsers) OCSP checking is probably preferred because OCSP responses are very small, unlike CRLs which can be MEGABYTES! For modem users, CRLs from the very large ISPs are not practical, because they're so big. OCSP messages are small and quick. CRLs are great for servers that do client authentication, because they can fetch one CRL and use it until the next CRL comes out, and do unlimited revocation checks with that one CRL. Since a given user is likely to connect to the same server repeatedly, using a CRL is better than making an OCSP request for every user every time the user contacts the server. So, CRL fetching is turned off until the user manually fetches a CRL from the CA. CA's who want browser users to use their CRLs can facilitate that by having a link on their web server to download a CRL. IINM, use of CRLs in that other browser is controlled by a single checkbox in a control panel, and is off by default. OCSP is turned off by default in mozilla, because frankly, a lot of home-grown CAs put out certs that claimed they did OCSP, when they didn't. So, mozilla would get one of their certs (e.g. from an https server), try to contact the OCSP server (and fail), and then claim the cert is revoked (the RIGHT THING to do in that circumstance), much to the browser user's dismay! Now, mozilla is being criticized by people unfamiliar with these issues for not enabling CRL fetching and OCSP use for all CAs by default. I can think of a few things that might help this situation, and here are some suggestions: 1. Make it easier for users to fetch that first CRL from the CA. Create a button in cert manager's CA panel that says try to fetch CRL. It would be unavailable (e.g. gray or gone) if the CA's cert doesn't include an extension that says how to get the CRL. 2. Make OCSP fetching be configured on a CA-by-CA basis, not globally. Take the global preference for OCSP out, and add an OCSP check box in the certificate manager in the panel of CA certs. It would be unavailable if the CA's cert doesn't have an extension that identifies the OCSP server. These proposed changes may or may not require changes to NSS. They definitely would require changes to PSM. -- Nelson B ___ mozilla-crypto mailing list
Re: On turning CRL and OCSP checking on by default.
Alex, Deacon, Alex wrote: 1) Although the option to perform cert validation (either via OCSP or CRL) should be a user configurable option, I believe that the application should ship with this option turned ON by default. It would be nice, but I wonder how many users would complain about all the sites not working ... A lot of OCSP servers have been incorrectly (and that includes Verisign's). I think the option should be off by default for clients, certainly for CRLs, which get very large and are not suitable from most clients at low bandwidth under any circumstances. 2) The decision as to what mechanism the client should use to validate a cert needs to be dictated by the CA, not the user, using the CDP and/or AIA extension. So instead of a ca-by-ca config as you describe, I would rather see something like this - * If there is only a CDP , then the browser should fetch the CRL. This could be implemented in PSM. It would have to download the CRL and import it to the local database. * If there is only a AIA extension, then the browser should send an OCSP request. Currently NSS will automatically do an OCSP check if the AIA extension is present. This occurs even if the cert was checked against a CRL also. * If there is both an AIA and CDP extension, the browser must send an OCSP request first. If OCSP fails, then it should then fall back to using a CRL. This would require code changes to NSS. Currently the policy is to always check CRLs first (among the locally available ones in the database), then OCSP (if enabled). 3) All CRL's and OCSP responses should be cached locally by the browser, ideally the cert/crl cache would be separate from the standard web cache (which can be flushed/turnedoff/etc) The browser should never hit the wire if it already has access to a fresh (current non-expired) CRL or OCSP response. There is already a local (in-memory) cache in NSS for full CRLs. There is not one yet for OCSP responses. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
It would be nice, but I wonder how many users would complain about all the sites not working ... A lot of OCSP servers have been incorrectly (and that includes Verisign's). I think the option should be off by default for clients, certainly for CRLs, which get very large and are not suitable from most clients at low bandwidth under any circumstances. with OCSP, shouldn't the CAs have some quality assurance to fix these kinds of problems in a timely manner, I'm sure this is possibly under the wrong thread, but this relates back to the pre/post CA checks... or at least I percieve it to... ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
