31
edits
NSS libPKIX Brainstorming: Difference between revisions
→Identified Tasks for the First Release
| (14 intermediate revisions by the same user not shown) | |||
| Line 19: | Line 19: | ||
==Integration Approach== | ==Integration Approach== | ||
LibPKIX API provides wide set of types and functions that user should know about and call to set up and run certificate chain building and/or validation. It is agreed that to improve a user experience nss should provide simpler way to access the functionality provided by the library. Existing libPKIX API should be kept private for all external users of NSS. NSS on it's turn should provide a wrapper - a new API, that will bridge the two libraries and will provide easy access to libPKIX certificate validation engine. | |||
LibPKIX validation algorithm implementation is a superior to current NSS implementation in two main areas: | |||
* it is capable to operate in bridge ca environment | |||
* it takes in to the account certificate/user policies. | |||
Today NSS truck has two different implementation of validation algorithm represented by NSS API(CERT_Verify*) and LibPKIX API(PKIX_Build and PKIX_Validate). The two APIs may produce two different, even possibly opposite, answers as a result of their differences. Two avoid asynchronous answers, an old implementation of NSS certificate validation API will be rewritten to call the new libPKIX API. In it's turn, a call to old NSS API will added the new libPKIX API. These two calls will be controlled by the validation engine switch, a control of which will be available to a user by either an environment variable or a programmatic API. | |||
To be expanded | |||
To be able to use most of the features provided by libPKIX, users will need to pass extra parameters to libPKIX(extra parameters compare to current NSS cert validation API) in order to utilize the algorithm that is capable to validate certificate chain while taking in account certificate policy extensions. Extra parameters will also be needed to activate different libPKIX features like use of LDAP and HTTP cert stores, to set revocation options and required name constraints. Return parameter will also be expanded and will include a valid certificate chain and a valid policy tree associated with validated certificate and requested policy parameters. | |||
But in most of the times parameters provided by the old NSS API should be sufficient to receive a valid result from libPKIX provided that the rest of the required parameters are set to the default. And so, an old CERT_Verify* functions should be used when ever caller has no extra parameters, such as policies parameters. In other cases a caller should use the new API when extra new parameters are available for certificate chain validation or there is a need for further process of extra values, such as valid cert chain and policy tree, return by libPKIX. | |||
In addition some changes will be made through out the NSS libraries because two reasons: | |||
* internally NSS makes quite a few CERT_Verify* function calls. I've counted up to 30 of direct and indirect calls to these functions. All these cases should be reviewed and changed if requited. | |||
* extra set of parameters and validation should be propagated to caller application. | |||
* changes to chain building process(see "Open Questions") | |||
Note, that non of the current applications that use NSS library at ReadHat and Sun sides are ready to provide extended set of parameter at the present time. The only major requirement for the first release is to provide a set of valid policies associated with validated certificate. | |||
==Open Questions== | ==Open Questions== | ||
| Line 63: | Line 77: | ||
**Certificate traversal time for 106 certs with ckbi installed is around 2600 microseconds. | **Certificate traversal time for 106 certs with ckbi installed is around 2600 microseconds. | ||
==Identified Tasks== | ==Identified Tasks for the First Release == | ||
*The libPKIX development branch contains changes to existing NSS source files. These have not yet landed on NSS trunk. TODO: | *The libPKIX development branch contains changes to existing NSS source files. These have not yet landed on NSS trunk. TODO: | ||
| Line 81: | Line 95: | ||
***The internals of the implementation of the function are written. Finalizing API design. For more information see [https://bugzilla.mozilla.org/show_bug.cgi?id=294531 bug 294531] | ***The internals of the implementation of the function are written. Finalizing API design. For more information see [https://bugzilla.mozilla.org/show_bug.cgi?id=294531 bug 294531] | ||
**keep all existing verification API, but change their implementation to call libPKIX functions | **keep all existing verification API, but change their implementation to call libPKIX functions | ||
***The following is the list of functions that form the NSS chain building/validation API, which potentially will be modified: | ***The following is the list of functions that form the NSS chain building/validation API, which potentially will be modified: | ||
****Cert chain build functions: | ****Cert chain build functions: | ||
| Line 93: | Line 106: | ||
*****CERT_VerifyCertNow | *****CERT_VerifyCertNow | ||
*****CERT_VerifyCACertForUsage | *****CERT_VerifyCACertForUsage | ||
**Provide functionality to switch from the original NSS certificate chain validation implementation to the libPKIX implementation and back. | |||
**Implement Cert validity time and cert subject name overrides. These overrides make possible to skip certificate time and subject validation based on users blessing. | |||
***This is founded on the difference between the current cert validation implementation and the one in libPKIX. | |||
***But as Nelson mentioned that it may not be used anymore. Need to be verified | |||
**Alexei will start working on it after new API is finalized. | |||
*Merge patch | *Enhance certutil to support policy extensions and generate a CSR without regenerating a public key(reuse already generated public key). | ||
*Resolve code duplication in libPKIX. | |||
***Some NSS code was copied into the libPKIX source during the course of development. This was done to avoid delay of libPKIX development interruption related to the patch review process. | |||
***If this duplication can not be resolved, then the code in question should at least be brought up to date. | |||
*Merge patch related to CRL Distribution Point certificate extension, as well as CRL Issuing Distribution Point CRL extension. | |||
**Depends on the agreement with Entrust. Still pending... | **Depends on the agreement with Entrust. Still pending... | ||
* NSPR enhancement is needed in order to support related sockets. https://bugzilla.mozilla.org/show_bug.cgi?id=234130 Bug 234130] | * Enhancement to softoken: | ||
**to support issuing distribution point CRLs (IDP). | |||
**to support delta CRLs. | |||
* NSPR enhancement is needed in order to support related sockets. [https://bugzilla.mozilla.org/show_bug.cgi?id=234130 Bug 234130] | |||
*NSS internal libraries such as libSSL and libSMIME that utilize NSS chain building and validation features will need to be modified in order to leverage new functionalities provided by libPKIX. These changes are related to propagating policy parameters for certificate chain building/validation API from user application to NSS libraries and back. There are also open questions regarding changes in chain building process(See "Open Questions" 1-3) answers to that will result in NSS libraries modifications. | *NSS internal libraries such as libSSL and libSMIME that utilize NSS chain building and validation features will need to be modified in order to leverage new functionalities provided by libPKIX. These changes are related to propagating policy parameters for certificate chain building/validation API from user application to NSS libraries and back. There are also open questions regarding changes in chain building process(See "Open Questions" 1-3) answers to that will result in NSS libraries modifications.(See [https://bugzilla.mozilla.org/show_bug.cgi?id=324867 bug 324867] for a particular change that libSSL will require) | ||
*After all of above items are done, we will not be able to say that libPKIX NSS is fully integrated in NSS. There are number of features that PKIX/NSS/NSPR still lacks. Here is the list of bugs: [https://bugzilla.mozilla.org/buglist.cgi?cmdtype= | *After all of above items are done, we will not be able to say that libPKIX NSS is fully integrated in NSS. There are number of features that PKIX/NSS/NSPR still lacks. Here is the list of bugs: [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Components&product=NSS&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=PKIX&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= pkix bug list] | ||
**Bugs/features need to be reviewed and the target release should be assign for the ones that will hold 3.12 release. | **Bugs/features need to be reviewed and the target release should be assign for the ones that will hold 3.12 release. | ||
**Fix bugs that have 3.12 as the target release. | **Fix bugs that have 3.12 as the target release. | ||
* | *NSS tools must also be modified to to be able to use new API. | ||
*Tests and QA | |||
**Here is the set of goals that we need to achieve, listed in priority order: | **Here is the set of goals that we need to achieve, listed in priority order: | ||
***Combine PKIX test programs into a smaller number of programs and compile them statically. This will reduce the amount of memory each program takes and will allow us not to export (unnecessarily) private libPKIX functions. | |||
***Get performance numbers for libPKIX cert chain validation. -- Done. | ***Get performance numbers for libPKIX cert chain validation. -- Done. | ||
***Verify libPKIX certificate chain validation compatibility with NSS. This task will requires to possess very wide set of, preferably life, certificates. One way to obtain them is to use search engine to find variety of websites that can provide us site certificates and certificate chains. | ***Verify libPKIX certificate chain validation compatibility with NSS. This task will requires to possess very wide set of, preferably life, certificates. One way to obtain them is to use search engine to find variety of websites that can provide us site certificates and certificate chains. | ||
| Line 112: | Line 143: | ||
***Verify libPKIX certificate chain building compatibility with NSS. Same certificates that were used to check verifying compatibility can be used to for this task. | ***Verify libPKIX certificate chain building compatibility with NSS. Same certificates that were used to check verifying compatibility can be used to for this task. | ||
***Extended validation functionality testing provided by PKIX. This testing task includes checking validation based on policies and various certificate policy extensions. The current set of tests will be enough to verify that the libPKIX works correctly. But these tests will be modified to be launched using new NSS certificate chain validation API. | ***Extended validation functionality testing provided by PKIX. This testing task includes checking validation based on policies and various certificate policy extensions. The current set of tests will be enough to verify that the libPKIX works correctly. But these tests will be modified to be launched using new NSS certificate chain validation API. | ||
==Identified Tasks for the Next Release == | |||
*Allow user of a new API to validate cert based on Key usage. The current implementation of the NSS validation function allows a cert to be chosen by CERTCertificateUsage, but not by usage of the key contained in the certificate. As a result, the user cannot ask to validate a cert that was issued to be used as an ssl certificate, but can only be used for signing. | |||
*Implement an option that will turn on OCSP cert verification for leaf cert or a whole chain. Sometimes users prefer to limit the cert chain verification time. One of the ways to achieve this is by limiting network I/O by switching off OCSP cert verification for non-leaf certificates. | |||
*NIST cert validation policy. There are a couple of differences in how NIST treats the presence of a CRL, compared to NSS (for more info see [[https://bugzilla.mozilla.org/show_bug.cgi?id=233806 bug 233806]) : | |||
**if an issuer CRL is not present, this is considered an error (cert revoked). | |||
** if a CRL has a nextUpdate that is before the date against which a certificate is being verified, this is considered an error. | |||
*Define and implement an API that will abort chain building/validation upon user request. | |||
*HTTPS over SSL. See [https://bugzilla.mozilla.org/show_bug.cgi?id=205436 bug 205436] | |||
*Dynamically defined slop time. Sloptime is currently defined as global value (set by default to 24h) that nss library functions use to adjust cert validity time. libPKIX code will require some modification to allow sloptime to be set by cert chain validation function. | |||
*Proxy support. The current implementation of HTTP and ldap clients requires direct connection to servers. | |||
==References== | |||
*[http://libpkix.sourceforge.net/Libpkix Lib PKIX open-source web site.] | |||
*[http://csrc.nist.gov/pki/fbca/welcome.html Federal Bridge CA.] | |||
*[http://csrc.nist.gov/pki/documents/B2B-article.pdf Article on concepts of cross-certification and bridge CAs.] | |||
*[http://www.cio.gov/fpkipa/documents/fbca_cp_09-10-02.pdf X.509 Certificate policy for the Federal bridge CA.] | |||
*[http://csrc.nist.gov/pki/testing/x509paths.html NIST PKI test suite.] | |||
*RFC 3280 | |||