NSS: Difference between revisions

Jump to navigation Jump to search

NSS (view source)

Revision as of 22:45, 2 August 2005

2,218 bytes removed ,  2 August 2005
→‎NSS Specific Parameters in Module Specs
Line 96: Line 96:
     '''moduleDB''' - this library includes NSS specific functions to supply additional module specs for loading.
     '''moduleDB''' - this library includes NSS specific functions to supply additional module specs for loading.
     '''moduleDBOnly''' - this library has no PKCS #11 functions and is only used for loading additional modules.
     '''moduleDBOnly''' - this library has no PKCS #11 functions and is only used for loading additional modules.
  '''trustOrder''' - integer value specifying the order in which the trust information for certificates specified by tokens on this pkcs #11 library should be rolled up. '0' means that tokens on this library should not supply trust information (default). The relative order of two pkcs#11 libraries which have the same trustOrder value is undefined.
  '''trustOrder''' - integer value specifying the order in which the trust information for certificates specified by tokens on this PKCS #11 library should be rolled up. '0' means that tokens on this library should not supply trust information (default). The relative order of two pkcs#11 libraries which have the same trustOrder value is undefined.
  '''cipherOrder''' - integer value specifiying the order in which tokens are searched when looking for a token to do a generic operation (DES/Hashing, etc).
  '''cipherOrder''' - integer value specifiying the order in which tokens are searched when looking for a token to do a generic operation (DES/Hashing, etc).
  '''ciphers''' - comma separated list of ciphers this token will enable that isn't already enabled by the library (currently only '''FORTEZZA''' is defined) (case-insensitive)..
  '''ciphers''' - comma separated list of ciphers this token will enable that isn't already enabled by the library (currently only '''FORTEZZA''' is defined) (case-insensitive)..
Line 124: Line 124:
         '''hasRootCerts'''
         '''hasRootCerts'''
         '''hasRootTrust'''
         '''hasRootTrust'''
     '''timeout ''' - time in minutes before the current authentication should be rechecked.
     '''timeout''' - time in minutes before the current authentication should be rechecked.
     '''askpwd ''' - case-insensitive flag describing how password prompts should be manages:
     '''askpwd'''   - case-insensitive flag describing how password prompts should be manages:
         every
         '''every'''
    r
        '''timeout'''
        '''only'''




Line 137: Line 138:
library=core32.dll name="Litronic Netsign"
library=core32.dll name="Litronic Netsign"
</pre>
</pre>
----------------------------------------------------------------------------------
Some rationale, questions, issues, and ways I would like to use this:
Rationale:
First, I like the idea of easily turning a spec into a single NULL
terminated string. This allows me to provide interfaces in my library so
applications can load a single PKCS #11 library by simply specifying the
same string one would find in the 'database' file.
This is the primary reason for going to a single line of name value
pairs rather than a stanza file format.
Making the names case insensitive aids in hand editting the file format.
Ideally it should be realitively easy to hand edit the file, so the
parser should be realtively liberal in what it accepts.
Using multiple quote characters is more of a nesting issue. It allows
one to use the same parser to handle application specific parameters
without using a lot of escapes.
Issues:
Win32 file specs: should they have \'s in them or should the be
specified as forward slashes '/' using \ as the escape character causes
some problems with simple win32 filenames (which would have to take on
the form c:\\winnt\\system32\\mydll.dll for instance).
Do we need any token specific flags that are generic (like those I
specified for the NSS specific data)? If so is object ID the right way
to specify the specific token?
Should we specify application/library specific names to have some
heirarchy form (mozilla.NSS or aol.NSS)? or is a single level all that
is needed?
Do we want to specify a global libraryID that we can use to refer to a
specific PKCS #11 library across system boots?
My Usage:
One of the things I would like to be able to do is 'nest' configuration
files. I'd like to have a specific application instance which may point
to a machine-wide instance. The application would bootstrap with maybe
something like:
"pkcs11libaryList=file parameter='/space/myapp/config/pkcs11list'"
which in turn has pkcs #11 modules to load and then a line like:
pkcs11libraryList=file parameter='/etc/pkcs11list'
which loads the machine wide pkcs #11 modules. If this is of generic
interest we can specify a pkcs11LibraryList like this, otherwise I would
just hide it in the NSS specific parameters.
Relyea
439

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/10740"

Navigation menu