On 5/9/05, Jean-Marc Desperrier <[EMAIL PROTECTED]> wrote: > Ram A Moskovitz wrote: > > On 5/9/05, Jean-Marc Desperrier <[EMAIL PROTECTED]> wrote: > >>Well, OCSP can bring problems too. I really think this would be used in > >>a situation with a large number of users and small number of revoked > >>certificates, where CRL work well. > > > > I understand that your expectation is there are and will be relatively > > few extension publishers. I think that the less checking you do on the > > way into the process (authentication) the more revocations you will > > have and the larger your CRLs will be. Further as the number of users > > of FF increases this will become an economic pain point.
Reasonable comparison of small CRLs with cached OCSP service snipped. > Either way, they are problems to solve. The current code can not get CRL > on-demand, it must have them available before the validation, and the > OCSP code has several restrictions, it blocks the process and does not > support proxies. Fair point but these should be relatively easy to address. I'm guessing the CRL issue could be addressed primarily through packaging by including a CRL for each issuer and CA in the original distribution along with the URL that they were fetched from and an update schedule. IMO the correct way to address the CRL issue is a software change to follow CDPs for those CAs that support it and the hack above or something similar for other CAs. OCSP is also a software change although frankly I don't seem to encounter problems with OCSP checking turned on as "only if specified" so this may be more of a perception issue today; I understand the issue to be that there are certs out there with OCSP pointers that aren't backed by service - this has been addressed in the MF policy and should disappear as an issue soon although again this does not affect me, perhaps I am atypical in what sites as visit as well as my configuration. > One solution can be for the page where the extension is available to > push the CRL to the browser before starting the extension installation. > If no up to date CRL is provided, the installation just won't work. I think this is much better than nothing. > Another question is, do we check the validity only at installation or > later too ? That is a tough question, I don't know enough about the package management and installation scheme to address it directly. Checking at launch time (of the app or first touch of the extension in per-app-launch) will help eliminate accidental security problems but may not address intentional ones. > > What do you do with a piece of code signed by a certificate that > > you have as revoked once the certificate has expired? > > And how do you solve that with OCSP ? You keep certs indefinitly in the > OCSP responder ? That's a policy question. I can tell you we have private root customers for whom we do not turn off OCSP responses regardless of the expiration of the cert. Our CRL policy varies by usage - as a server certificate is someting that is always used live there is much less value to offering revocation information for it after it is outside its validity period than for software which may be found and downloaded way after expiration. > Anyway the current signature implementation in Mozilla > has no way of verifying signatures after the cert has expired. That's good and bad - it's a tricky issue. It means that extensions die after the developer stops re-signing them with current certificates. Timestamping is an approach that is used to extend the life of the signed package and as such VeriSign has been offering object timestamping services for years with two varieties , the original being PKCS detached timestamp and the newer one is RFC3161. This has been part of ActiveX for a long time and related ideas are used in several mobile OS platforms. _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
