Sean Leonard wrote: > The most glaring problem however is that when validation fails, such > as in the case of a revoked certificate, the API returns no > certificate chains
My understanding is that when you are doing certificate path building, and you have to account for multiple possibilities any any point in the path, there is no partial chain that is better to return than any other one, so libpkix is better off not even trying to return a partial chain. The old code could return a partial chain somewhat sensibly because it only ever considered one possible cert (the "best" one, ha ha) at each point in the chain. > and no log information. Firefox has also been bitten by this and this is one of the things blocking the switch to libpkix as the default mechanism in Firefox. However, sometime soon I may just propose that we change to handle certificate overrides like Chrome does, in which case the log would become much less important for us. See bug 699874 and the bugs that are referred to by that bug. > The only output (in the revoked case) is > SEC_ERROR_REVOKED_CERTIFICATE. This is extremely unhelpful because it > is a material distinction to know that the EE cert was revoked, > versus an intermediary or root CA. Does libpkix return SEC_ERROR_REVOKED_CERTIFICATE in the case where an intermediate has been revoked? I would kind of expect that it would return whatever error it returns for "could not build a path to a trust anchor" instead, for the same reason I think it cannot return a partial chain. > Such an error also masks other possible problems, such as whether > a certificate has expired, lacks trust bits, or other information. Hopefully, libpkix at least returns the most serious problem. Have you found this to be the case? I realize that "most serious" is a judgement call that may vary by application, but at least Firefox separates cert errors into two buckets: overridable (e.g. expriation, untrusted issuer) and too-bad-to-allow-user-override (e.g. revocation). > Per above, we never used non-blocking I/O from libpkix; we use it in > blocking mode but call it on a worker thread. Non-blocking I/O never > seemed to work when we tried it, and in general we felt that doing > anything more than absolutely necessary on the main thread was a > recipe for non-deterministic behavior. This is also what Firefox and Chrome do internally, and this is why the non-blocking I/O feature is not seen as being necessary. > The downside to blocking mode is that the API is one-shot: it is not > possible to check on the "progress" of validation until it magically > completes. When you have CRLs that are >> 10MB, this is an issue. > However, this can be worked around (e.g., calling it twice: once for > constructing a chain without revocation checking, and another time > with revocation checking), and one-shot definitely simplifies the > API for everyone. As I mentioned in another thread, it may be the case that we have to completely change the way CRL, OCSP, and cert fetching is done in libpkix, or in libpkix-based applications anyway, for performance reasons. I have definitely been thinking about doing things in Gecko in a way that is similar to what you suggest above. > We do not currently use HTTP or LDAP certificate stores with respect > to libpkix/the functionality that is exposed by CERT_PKIXVerifyCert. > That being said, it is conceivable that others could use this feature, > and we could use it in the future. We have definitely seen LDAP URLs in > certificates that we have to validate (for example), and although > Firefox does not ship with the Mozilla Directory (LDAP) SDK, > Thunderbird does. Therefore, we encourage the maintainers to leave it > in. We can contribute some test LDAP services if that is necessary for > real-world testing. Definitely, I am concerned about how to test and maintain the LDAP code. And, I am not sure LDAP support is important for a modern web browser at least. Email clients may be a different story. One option may be to provide an option to CERT_PKIXVerifyCert to disable LDAP fetching but keep HTTP fetching enabled, to allow applications to minimize exposure to any possible LDAP-related exploits. > Congruence or mostly-similar > behavior with Thunderbird is also important, as it is awkward to > explain to users why Penango provides materially different > validation results from Thunderbird. I expect that Thunderbird to change to use CERT_PKIXVerifyCert exclusively around the time that we make that change in Firefox, if not exactly at the same time. > From our testing, libpkix/PKIX_CERTVerifyCert is pretty close to RFC > 5280 as it stands. It would be cheaper and more useful for the > Internet community if the maintainers put the 5% more effort necessary > to "finish the job", than the 95% to break compliance. If this is > something that you want to see to believe, I can try to compile some > kind of a spreadsheet that illustrates how RFC 5280 stacks up with > the current PKIX_CERTVerifyCert behavior. It would be really awesome if you could do so. > As stated, we would like to move away from using > CERT_VerifyCertificate, > provided that CERT_PKIXVerifyCert is strictly better. > CERT_PKIXVerifyCert has significant gaps in functionality that need > to be addressed first. Thanks. Previously, we assumed it would be OK to switch all certificate path validation to libpkix, including callers of the old functions. (See bug 653572.) It is good to know that we need to be more careful here. > As I indicated back in July in the thread "Validating custom extended > key usage (EKU) with NSS", the PKIX API doesn't provide a way to > validate usages of anything other than e-mail, code signing, and > SSL/TLS [...] I hope that this area of the code is improved and > exposed to apps, rather than put in the scrap heap. I am not opposed to having such enhancements made to libpkix. But, also, I don't think it would be a good idea to wait for Mozilla or Google or Red Hat to implement such improvements unless/until we ever need them for our products. However, it seems like a straightforward improvement that would be relatively easy to review, so I think we could at least get it reviewed in a (relatively) timely manner and checked in. I encourage you to file a bug and submit a patch and test cases. Anyway, thanks again for the email. This was very useful. - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
