(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 sore point for many Apple users in the US government, so being able to better support their needs would be great for Chromium - and Firefox. The archives at http://lists.apple.com/archives/fed-talk/ give a good idea of some of the needs and complaints about Apple's lack of PKI robustness. Having worked on commercial software targeting these customers, and having use a variety of both open and closed-source crypto libraries in the past, I really do believe there is a huge value to developers in having libpkix and having it work well - but unfortunately that value can be hard to articulate, due to what are very closed/secretive environments in which this software gets used. To further expound on the value of libpkix (while also being /very/ aware of its many deficiencies), I would love to see the original goal of also having an OpenSSL-compatible libpkix implementation available. This would make libpkix a huge value-add for languages like Python/Perl/Ruby/PHP/etc which expose C-bindings, and potentially "fix" many of the security issues I see being introduced time and time again (no name validation, no basic constraints validation, no date validation, etc). So while I understand and appreciate the Firefox/NSS-centric view, I don't think that's the only perspective needed to look at libpkix. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
