439
edits
Changes
NSS
,→Network Security Services
Mozilla NSS documentation can be found at [http://www.mozilla.org/projects/security/pki/nss/].
NSS is undergoing it's third round of [[FIPS Validation]].
== PKCS #11 Module Specs ==
The following is a proposal to the PKCS #11 working group made in August 2001 for configuring PKCS #11 modules. NSS currently implements this proposal internally.
The file format consists of name/value pairs of the form =.
Each name/value pair is separated by a blank value. A single line,
terminated by a '\n', '\r\n', or '\r' represents a single pkcs #11 library.
Names can be any alpha/numeric combination, and are parsed case-insensitive.
Values can contain any printable ascii value, including UTF8 characters.
Values can contain imbedded blanks either through quoting the entire
value, or by escaping the imbedded blanks with '\'. The value is
considered quoted if the first character after the '=' is ', ", {, [,
(, or <. If the value is quoted, then the value is terminated with and
ending quote of the form ', ", ), ], }, or > matching the respective
starting quote. Ending quotes can be escaped. Imbedded '\' charaters are
considered escape characters for the next character in the stream. Note
that case must be preserved in the values.
Recognized Names:
All applications/libraries must be able recognize the following name values:
library - This specifies the path to the pkcs #11 library.
name - This specifies the name of the pkcs #11 library.
parameter - This specifies a pkcs #11 library parameter with the
application must pass to the pkcs #11 library at C_Initialize() time
(see below).
In additions applications/libraries should be able to ignore additional
name value pairs which specify application specific parameters. Of
course these application/libraries should be able to parse their own
name/value pairs.
Each of these name/value pairs are optional.
If the library is not specified, the line represents some application
specific meta configuration data. Other applications and libraries can
safely ignore this line.
If the name is not specified, the application can use the library path
to describe the pkcs #11 library in any UI it may have.
If the parameter is not specified, no parameters are passed to the PKCS
#11 module.
If the application/library does not find its application/library
specific data, it should use it's defaults for this pkcs #11 library.
Parameter Passing:
If the parameter is specified, the application/library will strip the
value out, processing any outter quotes and escapes appropriately, and
pass the parameter to the pkcs #11 library when it calls C_Initialize().
A new CK_C_INITIALIZE_ARGS structure is defined as
typedef struct CK_C_INITIALIZE_ARGS {
CK_CREATEMUTEX CreateMutex;
CK_DESTROYMUTEX DestroyMutex;
CK_LOCKMUTEX LockMutex;
CK_UNLOCKMUTEX UnlockMutex;
CK_FLAGS flags;
CK_VOID_PTR LibraryParameters;
CK_VOID_PTR pReserved;
} CK_C_INITIALIZE_ARGS;
Applications/libraries must set LibraryParameters to NULL if no
parameter value is specified. PKCS #11 libraries which accept parameters
must check if the 'new' pReserved field is NULL if and only if
LibraryParameters field is not NULL.
----------------------------------------------------------------------------------
Here are the NSS Application specific parameters which I intend to use.
This is data that I currently store in secmod.db, or intend to store
there in the near future. This isn't part of the generic spec, but I
include it to see if anyone thinks some of these valuse should be
promoted to the next level up. The only ones that seem to me to be
candidates would be cipherOrder, trustOrder, and perhaps some of the
slotParams
NSS="nss_params"
nss_params are themselves name/value pairs, parsed with the same rules
described above. Valid names inside nss_params are:
flags - comma separated list of flag values, parsed case-insensitive.
Valid flag values are:
internal - this library is actually the Netscape internal library
fips - this library is the Netscape internal fips library.
moduleListSource - this library can be queried for lists of more
PKCS #11 modules to load.
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 (this option will make more sense once I
publish the other proposal I have promised). '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).
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)..
slotParams - space separated list of name/value pairs where the name is
a slotID and the value is a space sparated list of parameters related to
that slotID.
Sample file:
library= name="Netscape Internal Crypto Module" parameters="configdir=/u/relyea/.netscape certprefix=secmod=secmod.db" NSS="Flags=internal,pkcs11module TrustOrder=1 CipherOrder=-1 ciphers= slotParams={0x1=[slotFlags='RSA,DSA,DH,RC4,RC2,DES,MD2,MD5,SHA1,SSL,TLS,PublicCerts,Random'] 0x2=[slotFlags='RSA' timeout=50 askpw=only]}"
library=dkck32.dll name="DataKey SignaSURE 3600" NSS="TrustOrder=50 ciphers= "
library=swft32.dll name="Netscape Software Fortezza" parameters="keyfile=/u/relyea/keyfile" NSS="TrustOrder=50 ciphers=FORTEZZA slotParams=0x1=[slotFlags='FORTEZZA']"
library=core32.dll name="Litronic Netsign"
----------------------------------------------------------------------------------
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.
