Jean-Marc Desperrier wrote: > I am not so convinced those elements are so absolutly required to > support EV certificates. After all, verisign did an EV extension that > works with the current Firefox, even if it's very certainly taking some > ugly short-cuts.
FYI, as I understand it, they did it by reimplementing certificate decoding in JavaScript.
L. David Baron wrote: > On Saturday 2007-07-21 14:27 -0400, Mike Connor wrote: >> sooner or later. Unless we're prepared to maintain our own fork for >> NSS until libpkix meets some relatively arbitrary codesize target, and I >> don't think we're at all prepared to do that.
> What is libpkix and why do we want it? Can we build NSS without it?
libPKIX supports EV, but EV is not the only reason for libPKIX. EV is just one reason of many to go to a certificate library that implements the whole PKIX standard. EV is one reason to integrate libPKIX into NSS and FireFox at this time.
Here's some background on libPKIX.
The existing certificate handling code in NSS is firmly stuck in time, at around the year 2000 or 2001. The world of PKI standards has evolved a LOT since then, and NSS is now catching up. Vista is already caught up. libPKIX will bring feature parity for the new Extended PKI (PKIX) standards to Mozilla products.
Certificates once were issued in simple hierarchies, or trees, with the highest level CA in any tree being the "root" CA, and the End Entity (EE) certs (e.g. server certs, end user certs) were called "leaf" certs. Any EE cert was a member of at most one tree. Starting from any EE cert, a trivial straight line walk took you straight to the root CA, with no particularly challenging decisions to make. That's the world for which NSS's current (pre-3.12) cert code was written.
But today's world allows certificates to have multiple issues, multiple parent CAs. Multiple trees of certs that were formerly separate may now be combined through intermediate CAs that have parents in multiple trees. Those are the so-called "bridge" CAs.
In a world where bridge CAs exist, the act of constructing a "chain" or "path" of certificates to be validated is no longer a trivial walk. It is now possible to start with an EE cert and construct multiple chains, each leading up to a different top-level CA cert. In this new world, those top level CAs are called "trust anchors" rather than "roots" because the process of cert path building creates a tree with the EE cert as its root, and the (formerly "root") CAs as leaves.
The challenge for cert verification software in this new world is to find the right path to the right trust anchor, with which to do the validation.
In the old world, any server with a cert for encryption, or any email user with a cert for signature verification, sent out its entire cert chain, with all the certs from its EE cert up to the "trust anchor". This was easy to do because there was only one such chain possible, since each EE cert chains up to just one root, and the sender always had all the certs in the chain.
In the new world, each possible recipient of that EE cert (each "relying party) may trust a different trust anchor, and may need to have a different chain, leading up to a trust anchor that the recipient trusts. No one chain constructed by the sender can satisfy all the recipients. So, the recipient of an EE cert now needs to be able to construct cert chains, starting with just the sender's EE cert. This means that the relying party needs to be able to go out and fetch CA certificates on the Internet, via http or LDAP. Constructing the right cert chain may literally mean going out and getting all the necessary certs over the internet.
This new world of "eXtended PKI" (PKIX) is defined in a 5-year old RFC, RFC 3280. There are already certain parts of the world (Japan and South Korea) where use of these new features is now normal and commonplace. NSS doesn't always play well in those worlds. IIRC, Mozilla Foundation has wanted to get caught up in this area in order to better penetrate markets like South Korea for quite some time.
So for 3 years now, the NSS team has been working on writing a new certificate library that fully conforms to the new PKIX standards. libPKIX is 60K+ lines of code, and it adds all the missing new features that are not patent encumbered.
Here's a question: would any of you be interested in a presentation on the world of PKIX? Maybe we could put something together to present at (say) Mozilla HQ?
Jean-Marc Desperrier wrote: > Mike Connor wrote: >> "Libpkix provides a much more complete an modern parsing of >> certificates, most importantly policy parsing and handling cross >> certificate environments correctly. Both of these are needed for EV >> (the primary driver of getting libpkix in). (It also includes such >> things a on the fly fetching of intermediate certs."
> I am not so convinced those elements are so absolutly required to > support EV certificates. After all, verisign did an EV extension that > works with the current Firefox, even if it's very certainly taking some > ugly short-cuts.
It *appears* to work, with Verisign's certs only. But it does not do all the right things to work with all the other CAs' EV certs.
Limiting an implementation to a single root CA simplifies the problem dramatically. One you have constructed the right cert chain, from the EE cert (End User or Server cert) to the right trust anchor ("root"), the actual chain validation is not too difficult. By assuming there is only one trust anchor of interest (e.g. Verisign's) you can even code the path validation code in JavaScript.
The hard part is constructing the right chain to validate. That's where the vast majority of new code is used. If you want Mozilla products to work in a new world of bridge CAs (including bridges over bridges) and incomplete cert chains, you need a real PKIX implementation.
Mike Connor wrote: > We'll need to post a plan for approvals going forward, since we're not > going to require approvals for the front end until after M8, given how > much work is going to be going on with rapid iteration.
I suggest we do that soon ;-)
Also, I'd like to suggest that all bugfixes (not new features) be allowed in the 1.9b1 timeframe with module owner approval. This gives module owners the responsibility of deciding whether a particular fix is too risky for the 1.9 branch.
On Sunday 2007-07-22 04:40 -0400, Mike Connor wrote:
> On 22-Jul-07, at 2:59 AM, Robert Sayre wrote: > > That doesn't sound reasonable. We are going to accept a very large > > body of code with known quality control problems.
> If you have evidence that libpkix has known quality control problems,
For what it's worth, I do.
I just got trace-malloc working on Windows, so I was looking at the list of what we leak when starting and shutting down Firefox. (It's hard to do that on Linux because GNOME and GTK don't bother freeing things on shutdown.)
Currently, all we do with libpkix when starting and shutting down the browser is initialize it. That is, we call PKIX_Initialize: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib... This creates 7 hash tables and a lock. NSS doesn't currently call PKIX_Shutdown. But if we had it wouldn't have helped us free the memory allocated when creating these 7 hash tables and a lock.
Why not?
PKIX has its own object system. Every object has, among other things, a reference count, a hash code, and a lock used to protect the reference count and the hash code: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib... (I'd note that using atomic operations for reference counts avoids the rather significant size overhead of the lock. And I'm skeptical that the average mutex needs to be put in a hash table.)
So, for example, this lock that we create is created in PKIX_PL_MonitorLock_Create: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib... which in turn calls PKIX_PL_Object_Alloc: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib... which makes sure to allocate the object header (above) in addition to the (one word) PKIX_PL_MonitorLockStruct. So this lock object is an 8 word struct that owns a PRLock (to protect its reference count and hash code) and a PRMonitor (for the locking exposed to the caller), which are not themselves small or simple objects (a PRLock is 132 bytes on Windows; a PRMonitor is three allocations, a 132 byte PRLock, a 132 byte PRCondVar, and a 12 byte PRMonitor). (PKIX_PL_Mutex_Create gives you something similar, except with two PRLocks instead of a PRMonitor and a PRLock.)
The hash tables, in turn, have their own PRLock to protect their reference count (like all objects) and a table lock to protect the table (an object created by PKIX_PL_Mutex_Create, which in turn has two PRLocks, one to protect its reference count and one to expose to the caller).
When we initialize libpkix, we tell it to use arenas for allocation, by passing PR_TRUE as the second parameter to PKIX_Initialize: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib... This means, through a bit of indirection, that the PKIX reference counting functions are no-ops: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib... This means that we'll never free all the locks that we allocate, something that I imagine could be a significant memory leak if we did more than create 7 hash tables and a lock. (For just that, it's 3312 bytes of leaked lock structures, excluding the 1 PKIX_PL_MonitorLockStruct, 7 PKIX_PL_MutexStructs, and their header (320 bytes) that were allocated in the arena.)
> On Sunday 2007-07-22 04:40 -0400, Mike Connor wrote:
> > On 22-Jul-07, at 2:59 AM, Robert Sayre wrote: > > > That doesn't sound reasonable. We are going to accept a very large > > > body of code with known quality control problems.
> > If you have evidence that libpkix has known quality control problems,
> For what it's worth, I do.
> I just got trace-malloc working on Windows, so I was looking at the > list of what we leak when starting and shutting down Firefox. (It's > hard to do that on Linux because GNOME and GTK don't bother freeing > things on shutdown.)
> Currently, all we do with libpkix when starting and shutting down > the browser is initialize it. That is, we call PKIX_Initialize:http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib... > This creates 7 hash tables and a lock. NSS doesn't currently call > PKIX_Shutdown. But if we had it wouldn't have helped us free the > memory allocated when creating these 7 hash tables and a lock.
> Why not?
> PKIX has its own object system. Every object has, among other > things, a reference count, a hash code, and a lock used to protect > the reference count and the hash code:http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib... > (I'd note that using atomic operations for reference counts avoids > the rather significant size overhead of the lock. And I'm skeptical > that the average mutex needs to be put in a hash table.)
> So, for example, this lock that we create is created in > PKIX_PL_MonitorLock_Create:http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib... > which in turn calls PKIX_PL_Object_Alloc:http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib... > which makes sure to allocate the object header (above) in addition > to the (one word) PKIX_PL_MonitorLockStruct. So this lock object is > an 8 word struct that owns a PRLock (to protect its reference count > and hash code) and a PRMonitor (for the locking exposed to the > caller), which are not themselves small or simple objects (a PRLock > is 132 bytes on Windows; a PRMonitor is three allocations, a 132 > byte PRLock, a 132 byte PRCondVar, and a 12 byte PRMonitor). > (PKIX_PL_Mutex_Create gives you something similar, except with two > PRLocks instead of a PRMonitor and a PRLock.)
> The hash tables, in turn, have their own PRLock to protect their > reference count (like all objects) and a table lock to protect the > table (an object created by PKIX_PL_Mutex_Create, which in turn has > two PRLocks, one to protect its reference count and one to expose to > the caller).
> When we initialize libpkix, we tell it to use arenas for allocation, > by passing PR_TRUE as the second parameter to PKIX_Initialize:http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib... > This means, through a bit of indirection, that the PKIX reference > counting functions are no-ops:http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib... > This means that we'll never free all the locks that we allocate, > something that I imagine could be a significant memory leak if we > did more than create 7 hash tables and a lock. (For just that, it's > 3312 bytes of leaked lock structures, excluding the > 1 PKIX_PL_MonitorLockStruct, 7 PKIX_PL_MutexStructs, and their > header (320 bytes) that were allocated in the arena.)
This message posted by dbaron seems to have been lost in the thread. I'm raising it to its own new thread header position.
I didn't see it in David's post, but he mentioned to me that the arena- based allocation of objects with non-LIFO allocation patterns, without a freelist to recycle arena-allocated objects who die in non-LIFO order, seems to be a problem too. That is, without LIFO allocation order, this code will bloat its arenas with uncollected garbage, potentially badly.
>From what I can see and what David demonstrates, libpkix has wrong-
headedly cloned Java's object model into C, in the most inefficient, not-seen-in-a-JVM-since-1995, unjustified for C code, and manifestly bloaty and leaky manner possible.
This is not code I want in Firefox 3. Something fairly radical needs to be done to fix this problem. Nothing, certainly not EV cert promises, justifies this quality problem.
----- bren...@mozilla.org wrote: > This message posted by dbaron seems to have been lost in the thread. > I'm raising it to its own new thread header position.
Thanks, Brendan. This definitely shouldn't be getting lost, and should be actively tracked. Is status being monitored as part of the Gecko 1.9 meetings?
> I didn't see it in David's post, but he mentioned to me that the > arena- > based allocation of objects with non-LIFO allocation patterns, > without > a freelist to recycle arena-allocated objects who die in non-LIFO > order, seems to be a problem too. That is, without LIFO allocation > order, this code will bloat its arenas with uncollected garbage, > potentially badly.
> >From what I can see and what David demonstrates, libpkix has wrong- > headedly cloned Java's object model into C, in the most inefficient, > not-seen-in-a-JVM-since-1995, unjustified for C code, and manifestly > bloaty and leaky manner possible.
> This is not code I want in Firefox 3. Something fairly radical needs > to be done to fix this problem. Nothing, certainly not EV cert > promises, justifies this quality problem.
> Followups to m.d.planning.
It's pretty obvious that we shouldn't be taking code which is at best leaky and inefficient, and at worst potentially exploitable. What isn't as clear to me is:
1. What can be done to fix it, and what the timeline for fixing it would look like, 2. How badly we need the functionality it provides (not just EV!) in Firefox 3.
- updating NSS to catch up with PKI standards (hasn't been updated since 2001) - support for Extended PKI (PKIX, RFC 3280) --- multiple parent CAs --- already being used in Japan and Korea --- feature parity with Windows Vista - EV support
Assuming the next product delivery isn't for 6 months after Firefox 3, what's the cost to us for not supporting PKIX?
Mike Beltzner wrote: > Assuming the next product delivery isn't for 6 months after Firefox 3, what's the cost to us for not supporting PKIX?
Obviously I'm no expert here :-) but would there be a harm in not pushing back FF3 for this. And issuing a "feature security upgrade" in between FF3 and FF4 if we get this situation ironed out in that timeframe?
I am surely not even close to aware of the amount of work that would entail, just throwing the idea out there.
On Wed, 15 Aug 2007 19:10:26 -0000, bren...@mozilla.org wrote: > I didn't see it in David's post, but he mentioned to me that the arena- > based allocation of objects with non-LIFO allocation patterns, without > a freelist to recycle arena-allocated objects who die in non-LIFO
Nit: "arena-allocated objects s/who/which/ die"
Phil
-- Philip Chee <phi...@aleytys.pc.my>, <philip.c...@gmail.com> http://flashblock.mozdev.org/http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. [ ]Hello.. Incontinence Hotline.. Can you hold? * TagZilla 0.066.6
On Aug 15, 2:40 pm, Mike Beltzner <beltz...@mozilla.com> wrote:
> Assuming the next product delivery isn't for 6 months after Firefox 3, what's the cost to us for not supporting PKIX?
I'm not convinced that the owners should not just fix it. The changes would be mostly mechanical. Possibly Taras's Elsa-based patch generating tools could help, or maybe it would just take a pot of coffee and a good keyboard.
On 17-Aug-07, at 1:06 AM, bren...@mozilla.org wrote:
> On Aug 15, 2:40 pm, Mike Beltzner <beltz...@mozilla.com> wrote: >> Assuming the next product delivery isn't for 6 months after >> Firefox 3, what's the cost to us for not supporting PKIX?
> I'm not convinced that the owners should not just fix it. The changes > would be mostly mechanical. Possibly Taras's Elsa-based patch > generating tools could help, or maybe it would just take a pot of > coffee and a good keyboard.
I'd be willing to throw in a few bucks for one of the new Apple keyboards if that's all it takes. Do we have a point of contact who's engaging with the NSS team here?
Mike Beltzner wrote: > I'd be willing to throw in a few bucks for one of the new Apple > keyboards if that's all it takes. Do we have a point of contact who's > engaging with the NSS team here?
There are status meetings with the Firefox team and the NSS team. The intention was that they happen regularly, although I think we've only had one so far. The NSS team just sent a mail round wanting another one ASAP, but there was pushback because it's all-hands this week.
