We (me, Kai, Bob, Wan-Teh, Ryan, Elio, Kai) had a meeting today to discuss the
issues raised in this thread. We came to the following conclusions:
Ryan seems to be a great addition to the team. Welcome, Ryan!
Gecko (Firefox and Thunderbird) will make the switch to libpkix. See Ryan's
comments about his ideas for expanding Chromium's usage of libpkix.
We will reduce the complexity of libpkix in the following ways:
* We will drop the idea of supporting non-NSS certificate
library APIs, and we will remove the abstraction layers
over NSS's certhigh library. That means dropping the idea
of using libpkix in OpenSSL or in any OS kernel, for
example. Basically, much of the pkix_pl_nss layer can be
removed and/or folded into the core libpkix layer or into
certhigh, if doing so would be helpful.
* We will drop support for non-blocking I/O from libpkix.
It isn't working now, and we will remove the code that
handles the non-blocking case as we fix bugs, to make
the code easier to maintain.
* More generally, we will simplify the coding style to make
it easier to read, understand, and maintain. This includes
splitting large functions into smaller functions, removing
unnecessary abstractions, removing simple getter/setter
functions, potentially renaming internal (to libpkix)
functions to make the code easier to read, removing
non-PKCS#11 certificate stores (e.g. HTTP, LDAP), etc.
(I think we agreed to remove LDAP support, but also agreed
that it wasn't a high priority. This is a little unclear to
me.)
We are not going to attempt any kind of "spring cleaning" sprint on libpkix.
Basically, developers working on libpkix should feel free to do any of the
above when it helps simplify the implementation of an important fix or
enhancement to libpkix.
We will not consider complete RFC 5280 (et. al.) support a priority. We will
basically implement a subset of RFC 5280 (et al.), with an emphasis on features
used in the existing PKITS tests, and with the primary emphasis on making
existing real websites work securely and reliably. We will evaluate new RFC
5280 features and/or new additions to PKITS critically and make cost/benefit
and priority decisions on a feature-by-feature basis. Do not expect significant
new RFC 5280 (et. al.) functionality to be added to libpkix any time soon, even
if that functionality is specified by some (old) RFC already, unless that
functionality already has significant usage. If there is RFC 5280 (et al.)
functionality in libpkix that goes beyond what PKITS tests, then we may even
consider removing that functionality if it causes problems (e.g. security
vulnerabilities) and a "proper" fix for that feature is too time consuming. (I
don't think others are as eager to do this as I am, and it is diffi
cult to determine whether a feature is actually being relied upon or not, so I
consider this last thing to be somewhat unlikely and rare if it ever happens.)
We did not come up with a plan on how to end-of-life the old "classic"
certificate path validation/building. It might be the case that certhigh is
implemented in a way enables us to easily make enhancements to it to improve
libpkix-based processing without breaking the old "classic" API. I am a little
skeptical that it will be easy to make improvements to certhigh to improve
libpkix without having to do significant extra work to keep the classic API
working.
In my opinion, it is a very good idea for applications to move to remove their
dependencies on the "classic" API. Once Firefox is using libpkix exclusively,
there will be little interest from Mozilla in fixing bugs in the "classic"
library, and I got the idea that others feel similarly.
Let me know if there is anything I missed or am mistaken about.
Cheers,
Brian
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
