Re: What exactly are the benefits of libpkix over the old certificate path validation library?
On 01/04/2012 05:56 PM, Brian Smith wrote: Robert Relyea wrote: On 01/04/2012 04:18 PM, Brian Smith wrote: Are you actually fetching intermediates? In the cases where you fetch the intermediates, the old code will not work! We don't fetch the intermediate if we already have it, or it's already sent in the SSL chain. If you are seeing some performance issue, perhaps it some other issue? (are you turning on CRL fetching?). I think we are misunderstanding each other. I'm not talking about revocation on intermediates. I'm talking about fetching intermediates themselves because they weren't included in the chain. I thought that is what you were talking about. That was certainly what I was talking about. We can just tell libpkix not to do OCSP fetching for intermediates. So, this particular performance issue isn't a blocker for switching to libpkix, as long as we make such a change before making libpkix the default. My point is that, in order to actually enable libpkix's ability to fetch intermediate certificates in Firefox, we will have to do a substantial amount of work to eliminate the performance regression that is inherent with the serial fashion that libpkix does OCSP fetching. In some ways, this might be a question of fast vs right but I am not sure that the right here is enough of benefit to justify the performance cost. Still, I would like to do the intermediate OCSP fetching if it can be made close to free, which means doing it in parallel with the EE OCSP fetch, AFAICT. If the OCSP responder is the same for the EE and intermediate certs, you can issue a single OCSP request (at least in theory). It would require some NSS code. (Persistent) caching of OCSP responses will help. But, caching won't help for the I just installed Firefox and now I am going to see how fast it is by going to twitter.com test. And, also, we haven't even started working on the persistent caching of OCSP responses in Firefox yet. What is the actual cost, BTW. persistent caching of OCSP responses are not likely to buy a whole lot. You still have to fetch the OCSP responses for the validity period of the response (usually something like 24 hours). bob - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: What exactly are the benefits of libpkix over the old certificate path validation library?
Robert Relyea a écrit : 7. libpkix can actually fetch CRL's on the fly. The old code can only use CRL's that have been manually downloaded. We have hacks in PSM to periodically load CRL's, which work for certain enterprises, but not with the internet. PSM's periodic CRL download's certainly quite broken, but OTOH on the fly CRL fetching certainly won't work either on the Internet with regard to the delay it induces. I'm ok if someone wanted to rework the libpkix code itself, but trying to shoehorn in the libpkix features into the old cert processing code is the longer path to getting to something stable. Note that the decision to move away from the old code was made by those who knew it best. Probably quite true, but the question of why libpkix is so big stays, it very unlikely it brings a value proportionate to it's size. In the best of world, I'd vote for a complete reworking of it. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: What exactly are the benefits of libpkix over the old certificate path validation library?
Brian Smith a écrit : 3. libpkix can enforce certificate policies (e.g. requiring EV policy OIDs). Can the non-libpkix validation? EV policy have been defined in a way that means they could be supported by a code that handles an extremely tiny part of all what's possible with RFC5280 certificate policies. They could even not be supported at all by NSS, and instead handled by a short bit of code inside PSM that inspects the certificate chain and extract the value of the OIDs. Given that the code above NSS needs anyway to have a list of EV OIDs/CA name hard coded (*if* I'm correct, I might be wrong on that one), it wouldn't change things that much actually. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: What exactly are the benefits of libpkix over the old certificate path validation library?
(resending from the correct address) On 01/04/2012 03:51 PM, Brian Smith wrote: Ryan Sleevi wrote: IIRC, libpkix is an RFC 3280 and RFC 4158 conforming implementation, while non-libpkix is not. That isn't to say the primitives don't exist - they do, and libpkix uses them - but that the non-libpkix path doesn't use them presently, and some may be non-trivial work to implement. It would be helpful to get some links to some real-world servers that would require Firefox to do complex path building. Mostly in the government. They higher 3rd parties to replace our current path processing because it is non-conformant. In the real world, FF is basically holding the web back because we are the only major browser that is not RFC compliant! We should have had full pkix processing 5 years ago! To echo what Bob is saying here, in past work I saw problems on a weekly basis with non-3280 validating libraries within the areas of government, military, and education - and these are not just US-only problems. The 'big ideas' of PKI tended not to take off commercially, especially in the realm of ecommerce, but huge amounts of infrastructure and energy has been dedicated to the dream of PKI elsewhere. While you talk about the needs of Firefox with regards to NSS' future, I think it is important to realize that libpkix is the only /open/ implementation (at least, as far as I know) that even comes close to 3280/5280, at least as is available to C/C++ applications. The next closest is probably Peter Gutmann's cryptlib, which unfortunately is not widely used in open-source projects. Note, for other languages, you have Sun/Oracle's Java implementation (which libpkix mirrors a very early version of, as discussed in the libpkix history) and the Legion of the Bouncy Castle's C# implementation. These are the same customers who are often beholden to keep IE 6/ActiveX around for legacy applications. So while much energy is being put forth (including from Microsoft) to move these organizations to 'modern' systems that can support a richer web, if their security needs can't be met by Firefox, then there will be a problem (or, like Bob said, they'll make their own - and weigh that as a cost against switching from MSFT). A couple examples would include the GRID project (which uses a cross-certified mesh - http://www.igtf.net/), the US government's Federal PKI Bridge CA ( https://turnlevel.com/wp-content/uploads/2010/05/FederalBridge.gif ), and the DOD/DISA's PKI setup. The layout of the DOD PKI is fairly similar to those among various European identity card PKIs, with added cross-certification for test roots so that third-parties can develop interoperable software. However, even outside the spectrum of government/enterprise, you still see issues that 3280/5280 address better than the current non-libpkix implementation. EV certificates (and soon, the CA/B Forum Baseline Specifications) rely on proper policy OID validation - but the failure to match the OID is not a validation failure, it's just a sign of a 'lesser' level of identity assurance. CA key rollover is incredibly common. Likewise, as CAs buy eachother out, you end up with effectively bridge or mesh topologies where they cross-certify eachother for legacy systems. As far as non-TLS-compliant servers, I think that's an oversimplification. It relies on the assumption that 1) There is one and only one root certificate 2) the server knows all the trust anchors of the client. Both statements can be shown to be demonstrably false (just look at how many cross-certified verisign or entrust roots there are, due to CA key rollovers). So there is no reasonable way for a server to send a client a 'complete' chain, nor to send them a chain that they can know will validate to the clients trust anchors. At best, only the EE cert matters. For all of these reasons, I really do think libpkix is a huge step forward - and it's many nuances and bugs can be things we should work on solving, rather than trying to determine some minimal set of functionality and graft that onto the existing pre-libpkix implementation. Speaking with an individual hat on, there are only a few reasons I can think of why Chromium /wouldn't/ want to use libpkix universally on all supported platforms: 1) On Windows, CryptoAPI simply is a more robust (5280 compliant) and extendable implementation - and many of these government/enterprise sectors have extended it, in my experience, so having Chromium ignore those could be problematic. 2) On Mac, I haven't had any time to explore developing a PKCS#11 module that can read Keychain/CDSA-based trust anchors and trust settings. I would be absolutely thrilled to be able to use libpkix for the Mac implementation - Apple's path building/chain validation logic is horrid (barely targets RFC 2459), and they're on their way to deprecating every useful API that returns meaningful information, over-simplifying it to target the iOS market. This has been a
Re: Developing pkcs11 module for Firefox
On 2012-01-05 02:45, Robert Relyea wrote: I am curious as to how smartcard management is supposed to work for Linux. It seems to me that it would be ideal for Firefox to support the shared DB on Linux. Are there OS-level tools for managing the shared DB. For example, is there an OS-level UI for adding/removing PKCS#11 modules in Fedora/RHEL that would make Firefox's UI for this redundant? System level PKCS #11 modules (installed by the administrater) are stored in /etc/pki/nssdb, user level pkcs #11 modules (installed by the user) are stored in ~/.pki/nssdb . User level application load both the system modules and the user modules. Now this works under the covers is described here: https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX Doesn't Gnome Keyring essentially shoot for the same target? -- Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: What exactly are the benefits of libpkix over the old certificate path validation library?
On 01/04/2012 03:51 PM, Brian Smith wrote: Ryan Sleevi wrote: IIRC, libpkix is an RFC 3280 and RFC 4158 conforming implementation, while non-libpkix is not. That isn't to say the primitives don't exist - they do, and libpkix uses them - but that the non-libpkix path doesn't use them presently, and some may be non-trivial work to implement. It would be helpful to get some links to some real-world servers that would require Firefox to do complex path building. Mostly in the government. They higher 3rd parties to replace our current path processing because it is non-conformant. In the real world, FF is basically holding the web back because we are the only major browser that is not RFC compliant! We should have had full pkix processing 5 years ago! To echo what Bob is saying here, in past work I saw problems on a weekly basis with non-3280 validating libraries within the areas of government, military, and education - and these are not just US-only problems. The 'big ideas' of PKI tended not to take off commercially, especially in the realm of ecommerce, but huge amounts of infrastructure and energy has been dedicated to the dream of PKI elsewhere. While you talk about the needs of Firefox with regards to NSS' future, I think it is important to realize that libpkix is the only /open/ implementation (at least, as far as I know) that even comes close to 3280/5280, at least as is available to C/C++ applications. The next closest is probably Peter Gutmann's cryptlib, which unfortunately is not widely used in open-source projects. Note, for other languages, you have Sun/Oracle's Java implementation (which libpkix mirrors a very early version of, as discussed in the libpkix history) and the Legion of the Bouncy Castle's C# implementation. These are the same customers who are often beholden to keep IE 6/ActiveX around for legacy applications. So while much energy is being put forth (including from Microsoft) to move these organizations to 'modern' systems that can support a richer web, if their security needs can't be met by Firefox, then there will be a problem (or, like Bob said, they'll make their own - and weigh that as a cost against switching from MSFT). A couple examples would include the GRID project (which uses a cross-certified mesh - http://www.igtf.net/), the US government's Federal PKI Bridge CA ( https://turnlevel.com/wp-content/uploads/2010/05/FederalBridge.gif ), and the DOD/DISA's PKI setup. The layout of the DOD PKI is fairly similar to those among various European identity card PKIs, with added cross-certification for test roots so that third-parties can develop interoperable software. However, even outside the spectrum of government/enterprise, you still see issues that 3280/5280 address better than the current non-libpkix implementation. EV certificates (and soon, the CA/B Forum Baseline Specifications) rely on proper policy OID validation - but the failure to match the OID is not a validation failure, it's just a sign of a 'lesser' level of identity assurance. CA key rollover is incredibly common. Likewise, as CAs buy eachother out, you end up with effectively bridge or mesh topologies where they cross-certify eachother for legacy systems. As far as non-TLS-compliant servers, I think that's an oversimplification. It relies on the assumption that 1) There is one and only one root certificate 2) the server knows all the trust anchors of the client. Both statements can be shown to be demonstrably false (just look at how many cross-certified verisign or entrust roots there are, due to CA key rollovers). So there is no reasonable way for a server to send a client a 'complete' chain, nor to send them a chain that they can know will validate to the clients trust anchors. At best, only the EE cert matters. For all of these reasons, I really do think libpkix is a huge step forward - and it's many nuances and bugs can be things we should work on solving, rather than trying to determine some minimal set of functionality and graft that onto the existing pre-libpkix implementation. Speaking with an individual hat on, there are only a few reasons I can think of why Chromium /wouldn't/ want to use libpkix universally on all supported platforms: 1) On Windows, CryptoAPI simply is a more robust (5280 compliant) and extendable implementation - and many of these government/enterprise sectors have extended it, in my experience, so having Chromium ignore those could be problematic. 2) On Mac, I haven't had any time to explore developing a PKCS#11 module that can read Keychain/CDSA-based trust anchors and trust settings. I would be absolutely thrilled to be able to use libpkix for the Mac implementation - Apple's path building/chain validation logic is horrid (barely targets RFC 2459), and they're on their way to deprecating every useful API that returns meaningful information, over-simplifying it to target the iOS market. This has been a sore point for many Apple users in
Re: Regarding PSM with external SSL library
Hi Brian, We'll go with your suggestion of using NSS after size reduction for this project for our security requirements. But right now we cannot upgrade to latest firefox due to the current schedule and resources we have for this project. We will follow the guidelines listed in the 611781 as well your other suggestions in the mail. It will be great if you can support us if we hit a roadblock. We will update on the progress soon. Thanks. Ashok -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: What exactly are the benefits of libpkix over the old certificate path validation library?
Jean-Marc Desperrier wrote: Brian Smith a écrit : 3. libpkix can enforce certificate policies (e.g. requiring EV policy OIDs). Can the non-libpkix validation? EV policy have been defined in a way that means they could be supported by a code that handles an extremely tiny part of all what's possible with RFC5280 certificate policies. Right. How much of PKIX a client actually needs to implement is still an open question in my mind. They could even not be supported at all by NSS, and instead handled by a short bit of code inside PSM that inspects the certificate chain and extract the value of the OIDs. Given that the code above NSS needs anyway to have a list of EV OIDs/CA name hard coded (*if* I'm correct, I might be wrong on that one), it wouldn't change things that much actually. AFAICT, it is important that you know the EV policy OID you are looking for during path building, because otherwise you might build a path that has a cert without the EV policy even when there is another possible path that uses certs that all have the policy OID. On the other hand, do we really need to do path building at all? It seems reasonable to me to require that sites that want EV treatment to return (in their TLS Certificates message) a pre-constructed path with the correct certs (all with the EV policy OID) to verify (sans root), which is what the TLS specification requires anyway. So, I would say that, AFAICT, practical EV support doesn't really require PKIX processing, though other things might. - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Regarding PSM with external SSL library
Ashok Subash wrote: We'll go with your suggestion of using NSS after size reduction for this project for our security requirements. But right now we cannot upgrade to latest firefox due to the current schedule and resources we have for this project. We will follow the guidelines listed in the 611781 as well your other suggestions in the mail. It will be great if you can support us if we hit a roadblock. The best way to get such support is to attach ask questions and to post your patches in bugs in our bugzilla database. Try to write patches in a way that is beneficial to the overall NSS and Gecko (Firefox) projects, so that we can incorporate those patches into the mainline Gecko and/or NSS source code. If you identify new ways to shrink NSS besides the ways listed in those bugs, then please file new bugs and document your findings in them (And please CC me in the bug report). It is likely that any such reductions in the size of NSS that you make for Firefox 3.6 will be applicable to Firefox 12+ as our usage of NSS hasn't changed much between 3.6 and 12. Whenever I get around to working on bug 611781, the improvements I make will probably benefit your project as well (possibly requiring some small modifications.) - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: What exactly are the benefits of libpkix over the old certificate path validation library?
Robert Relyea a écrit : On 01/04/2012 05:56 PM, Brian Smith wrote: Robert Relyea wrote: On 01/04/2012 04:18 PM, Brian Smith wrote: In the cases where you fetch the intermediates, the old code will not work! [...] I'm talking about fetching intermediates themselves because they weren't included in the chain. I thought that is what you were talking about. That was certainly what I was talking about. Well, as Rob noted that's *very* surprising because the standard code will *not* work in that case, so you're talking about a case that's broken in the non-libpkix world which should be a rare case. And not the one where performance is the main concern. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
