Package: libnss3-tools
Version: 2:3.106-1
Severity: minor
Tags: upstream
* What led up to the situation?
Checking for defects with a new version
test-[g|n]roff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z < "man
page"
[Use "groff -e ' $' <file>" to find trailing spaces.]
["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).
[The fate of "test-nroff" was decided in groff bug #55941.]
* What was the outcome of this action?
troff:<stdin>:464: warning: trailing space in the line
troff:<stdin>:465: warning: trailing space in the line
troff:<stdin>:466: warning: trailing space in the line
troff:<stdin>:488: warning: trailing space in the line
troff:<stdin>:489: warning: trailing space in the line
troff:<stdin>:513: warning: trailing space in the line
troff:<stdin>:550: warning: trailing space in the line
* What outcome did you expect instead?
No output (no warnings).
-.-
General remarks and further material, if a diff-file exist, are in the
attachments.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libnss3-tools depends on:
ii libc6 2.40-4
ii libnspr4 2:4.36-1
ii libnss3 2:3.106-1
ii zlib1g 1:1.3.dfsg+really1.3.1-1+b1
libnss3-tools recommends no packages.
libnss3-tools suggests no packages.
-- no debconf information
Input file is pk12util.1
Any program (person), that produces man pages, should check the output
for defects by using (both groff and nroff)
[gn]roff -mandoc -t -ww -b -z -K utf8 <man page>
The same goes for man pages that are used as an input.
For a style guide use
mandoc -T lint
-.-
So any 'generator' should check its products with the above mentioned
'groff', 'mandoc', and additionally with 'nroff ...'.
This is just a simple quality control measure.
The 'generator' may have to be corrected to get a better man page,
the source file may, and any additional file may.
Common defects:
Input text line longer than 80 bytes.
Not removing trailing spaces (in in- and output).
The reason for these trailing spaces should be found and eliminated.
Not beginning each input sentence on a new line.
Lines should thus be shorter.
See man-pages(7), item 'semantic newline'.
-.-
The difference between the formatted output of the original and patched file
can be seen with:
nroff -mandoc <file1> > <out1>
nroff -mandoc <file2> > <out2>
diff -u <out1> <out2>
and for groff, using
"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -mandoc -Z - "
instead of 'nroff -mandoc'
Add the option '-t', if the file contains a table.
Read the output of 'diff -u' with 'less -R' or similar.
-.-.
If 'man' (man-db) is used to check the manual for warnings,
the following must be set:
The option "-warnings=w"
The environmental variable:
export MAN_KEEP_STDERR=yes (or any non-empty value)
or
(produce only warnings):
export MANROFFOPT="-ww -b -z"
export MAN_KEEP_STDERR=yes (or any non-empty value)
-.-.
Output from "mandoc -T lint pk12util.1": (shortened list)
36 input text line longer than 80 bytes
13 skipping paragraph macro
-.-.
Output from "test-groff -mandoc -t -ww -z pk12util.1": (shortened list)
7 trailing space in the line
-.-.
Remove space characters (whitespace) at the end of lines.
Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".
Number of lines affected is
9
-.-.
Strings longer than 3/4 of a standard line length (80)
Use "\:" to split the string at the end of an output line, for example a
long URLs (web address)
122 The nickname can also be a PKCS #11 URI\&. For example, if you have a
certificate named "my\-server\-cert" on the internal certificate store, it can
be unambiguously specified as
"pkcs11:token=NSS%20Certificate%20DB;object=my\-server\-cert"\&. For details
about the format, see RFC 7512\&.
854 \m[blue]\fBhttp://www\&.mozilla\&.org/projects/security/pki/nss/\fR\m[]\&;.
The NSS site relates directly to NSS code changes and releases\&.
-.-.
Wrong distance between sentences in the input file.
Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").
The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.
Remember coding: Only one command ("sentence") on each (logical) line.
E-mail: Easier to quote exactly the relevant lines.
Generally: Easier to edit the sentence.
Patches: Less unaffected text.
Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.
The amount of space between sentences in the output can then be
controlled with the ".ss" request.
Mark a final abbreviation point as such by suffixing it with "\&".
N.B.
The number of lines affected can be too large to be in a patch.
37:This documentation is still work in progress\&. Please contribute to the
initial review in
42:\fBpk12util\fR, enables sharing certificates among any server that supports
PKCS #12\&. The tool can import certificates and keys from PKCS #12 files into
security databases, export certificates, and list certificates and keys\&.
83:pkcs11\&.txt)\&. If the prefix
110:Specify the hash algorithm used in the pkcs #12 mac\&. This algorithm also
specifies the HMAC used in the prf when using pkcs #5 v2\&.
122:The nickname can also be a PKCS #11 URI\&. For example, if you have a
certificate named "my\-server\-cert" on the internal certificate store, it can
be unambiguously specified as
"pkcs11:token=NSS%20Certificate%20DB;object=my\-server\-cert"\&. For details
about the format, see RFC 7512\&.
127:Specify the prefix used on the certificate and key databases\&. This option
is provided as a special case\&. Changing the names of the certificate and key
databases is not recommended\&.
132:Dumps all of the data in raw (binary) form\&. This must be saved as a DER
file\&. The default is to return information in a pretty\-print ASCII format,
which displays the information about the certificates and public keys in the
p12 file\&.
477:command to export certificates and keys requires both the name of the
certificate to extract from the database (\fB\-n\fR) and the PKCS
#12\-formatted output file to write to\&. There are optional parameters that
can be used to encrypt the file to protect the certificate material\&.
499:file are not human\-readable\&. The certificates and keys in the file can
be printed (listed) in a human\-readable pretty\-print format that shows
information for every certificate and any public keys in the
515: Friendly Name: Thawte Freemail Member\*(Aqs Thawte Consulting (Pty)
Ltd\&. ID
538:prints the certificates and then exports them into separate DER binary
files\&. This allows the certificates to be fed to another application that
supports
540:files\&. Each certificate is written to a sequentially\-number file,
beginning with
552: Friendly Name: Thawte Freemail Member\*(Aqs Thawte Consulting (Pty)
Ltd\&. ID
561:Certificate Friendly Name: Thawte Freemail Member\*(Aqs Thawte
Consulting (Pty) Ltd\&. ID
569:PKCS #12 provides for not only the protection of the private keys but also
the certificate and meta\-data associated with the keys\&. Password\-based
encryption is used to protect private keys on export to a PKCS #12 file and,
optionally, the associated certificates\&. If no algorithm is specified, the
tool defaults to using PKCS #12 SHA\-1 and 3\-key triple DES for private key
encryption\&. When not in FIPS mode, PKCS #12 SHA\-1 and 40\-bit RC4 is used
for certificate encryption\&. When in FIPS mode, there is no certificate
encryption\&. If certificate encryption is not wanted, specify
661:With PKCS #12, the crypto provider may be the soft token module or an
external hardware module\&. If the cryptographic module does not support the
requested algorithm, then the next best fit will be selected (usually the
default)\&. If no suitable replacement for the desired algorithm can be found,
the tool returns the error
665:NSS originally used BerkeleyDB databases to store security information\&.
The last versions of these
702:BerkeleyDB has performance limitations, though, which prevent it from being
easily used by multiple applications simultaneously\&. NSS has some flexibility
that allows applications to use their own, independent database engine while
keeping a shared database and working around the access issues\&. Still, NSS
requires more flexibility to provide a truly shared security database\&.
704:In 2009, NSS introduced a new set of databases that are SQLite databases
rather than BerkleyDB\&. These new databases provide more accessibility and
performance:
741:database type\&. The shared database type is preferred; the legacy format
is included for backward compatibility\&.
747:prefix with the given security directory\&. For example:
821:accepts password\-based encryption schemes not listed in this document\&.
However, those schemes are not officially supported and may have issues in
interoperability with other tools\&.
854:\m[blue]\fBhttp://www\&.mozilla\&.org/projects/security/pki/nss/\fR\m[]\&;.
The NSS site relates directly to NSS code changes and releases\&.
866:Licensed under the Mozilla Public License, v\&. 2\&.0\&. If a copy of the
MPL was not distributed with this file, You can obtain one at
http://mozilla\&.org/MPL/2\&.0/\&;.
-.-.
Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause; after punctuation marks.
N.B.
The number of lines affected can be too large to be in a patch.
Line 31, length 98
pk12util \- Export and import keys and certificate to or from a PKCS #12 file
and the NSS database
Line 34, length 343
\fBpk12util\fR [\-i\ p12File|\-l\ p12File|\-o\ p12File] [\-c\ keyCipher] [\-C\
certCipher] [\-d\ directory] [\-h\ tokenname] [\-m\ |\ \-\-key\-len\ keyLength]
[\-M\ hashAlg] [\-n\ certname] [\-P\ dbprefix] [\-r] [\-v] [\-\-cert\-key\-len\
certKeyLength] [\-k\ slotPasswordFile|\-K\ slotPassword] [\-w\
p12filePasswordFile|\-W\ p12filePassword]
Line 37, length 90
This documentation is still work in progress\&. Please contribute to the
initial review in
Line 42, length 229
\fBpk12util\fR, enables sharing certificates among any server that supports
PKCS #12\&. The tool can import certificates and keys from PKCS #12 files into
security databases, export certificates, and list certificates and keys\&.
Line 76, length 94
Specify the database directory into which to import to or export from
certificates and keys\&.
Line 85, length 87
is not used, then the tool assumes that the given databases are in the SQLite
format\&.
Line 105, length 88
Specify the desired length of the symmetric key to be used to encrypt the
private key\&.
Line 110, length 134
Specify the hash algorithm used in the pkcs #12 mac\&. This algorithm also
specifies the HMAC used in the prf when using pkcs #5 v2\&.
Line 115, length 110
Specify the desired length of the symmetric key to be used to encrypt the
certificates and other meta\-data\&.
Line 122, length 289
The nickname can also be a PKCS #11 URI\&. For example, if you have a
certificate named "my\-server\-cert" on the internal certificate store, it can
be unambiguously specified as
"pkcs11:token=NSS%20Certificate%20DB;object=my\-server\-cert"\&. For details
about the format, see RFC 7512\&.
Line 127, length 186
Specify the prefix used on the certificate and key databases\&. This option is
provided as a special case\&. Changing the names of the certificate and key
databases is not recommended\&.
Line 132, length 240
Dumps all of the data in raw (binary) form\&. This must be saved as a DER
file\&. The default is to return information in a pretty\-print ASCII format,
which displays the information about the certificates and public keys in the
p12 file\&.
Line 442, length 142
for importing a certificate or key is the PKCS #12 input file (\fB\-i\fR) and
some way to specify the security database being accessed (either
Line 448, length 159
pk12util \-i p12File [\-h tokenname] [\-v] [\-d directory] [\-P dbprefix] [\-k
slotPasswordFile|\-K slotPassword] [\-w p12filePasswordFile|\-W p12filePassword]
Line 477, length 283
command to export certificates and keys requires both the name of the
certificate to extract from the database (\fB\-n\fR) and the PKCS
#12\-formatted output file to write to\&. There are optional parameters that
can be used to encrypt the file to protect the certificate material\&.
Line 479, length 242
pk12util \-o p12File \-n certname [\-c keyCipher] [\-C certCipher]
[\-m|\-\-key_len keyLen] [\-n|\-\-cert_key_len certKeyLen] [\-d directory] [\-P
dbprefix] [\-k slotPasswordFile|\-K slotPassword] [\-w p12filePasswordFile|\-W
p12filePassword]
Line 499, length 207
file are not human\-readable\&. The certificates and keys in the file can be
printed (listed) in a human\-readable pretty\-print format that shows
information for every certificate and any public keys in the
Line 503, length 159
pk12util \-l p12File [\-h tokenname] [\-r] [\-d directory] [\-P dbprefix] [\-k
slotPasswordFile|\-K slotPassword] [\-w p12filePasswordFile|\-W p12filePassword]
Line 515, length 81
Friendly Name: Thawte Freemail Member\*(Aqs Thawte Consulting (Pty) Ltd\&.
ID
Line 538, length 155
prints the certificates and then exports them into separate DER binary files\&.
This allows the certificates to be fed to another application that supports
Line 540, length 83
files\&. Each certificate is written to a sequentially\-number file, beginning
with
Line 552, length 81
Friendly Name: Thawte Freemail Member\*(Aqs Thawte Consulting (Pty) Ltd\&.
ID
Line 559, length 86
Certificate Friendly Name: Thawte Personal Freemail Issuing CA \- Thawte
Consulting
Line 561, length 92
Certificate Friendly Name: Thawte Freemail Member\*(Aqs Thawte Consulting
(Pty) Ltd\&. ID
Line 569, length 593
PKCS #12 provides for not only the protection of the private keys but also the
certificate and meta\-data associated with the keys\&. Password\-based
encryption is used to protect private keys on export to a PKCS #12 file and,
optionally, the associated certificates\&. If no algorithm is specified, the
tool defaults to using PKCS #12 SHA\-1 and 3\-key triple DES for private key
encryption\&. When not in FIPS mode, PKCS #12 SHA\-1 and 40\-bit RC4 is used
for certificate encryption\&. When in FIPS mode, there is no certificate
encryption\&. If certificate encryption is not wanted, specify
Line 620, length 138
SHA\-1 and 40\-bit RC4 (\fB"PKCS #12 V2 PBE With SHA\-1 And 40 Bit RC4"\fR)
(used by default for certificate encryption in non\-FIPS mode)
Line 631, length 91
SHA\-1 and 3\-key triple\-DES (\fB"PKCS #12 V2 PBE With SHA\-1 And 3KEY Triple
DES\-CBC"\fR
Line 661, length 326
With PKCS #12, the crypto provider may be the soft token module or an external
hardware module\&. If the cryptographic module does not support the requested
algorithm, then the next best fit will be selected (usually the default)\&. If
no suitable replacement for the desired algorithm can be found, the tool
returns the error
Line 665, length 100
NSS originally used BerkeleyDB databases to store security information\&. The
last versions of these
Line 702, length 382
BerkeleyDB has performance limitations, though, which prevent it from being
easily used by multiple applications simultaneously\&. NSS has some flexibility
that allows applications to use their own, independent database engine while
keeping a shared database and working around the access issues\&. Still, NSS
requires more flexibility to provide a truly shared security database\&.
Line 704, length 161
In 2009, NSS introduced a new set of databases that are SQLite databases rather
than BerkleyDB\&. These new databases provide more accessibility and
performance:
Line 736, length 129
pkcs11\&.txt, which is listing of all of the PKCS #11 modules contained in a
new subdirectory in the security databases directory
Line 741, length 115
database type\&. The shared database type is preferred; the legacy format is
included for backward compatibility\&.
Line 745, length 142
\fBmodutil\fR) assume that the given security databases use the SQLite type
Using the legacy databases must be manually specified by using the
Line 789, length 94
For an engineering draft on the changes in the shared NSS databases, see the
NSS project wiki:
Line 805, length 102
has changed over time, while importing files exported with older versions of
NSS is still supported\&.
Line 809, length 212
used the UTF\-16 encoding for the PKCS #5 password\-based encryption schemes,
while the recommendation is to encode passwords in UTF\-8 if the used
encryption scheme is defined outside of the PKCS #12 standard\&.
Line 821, length 185
accepts password\-based encryption schemes not listed in this document\&.
However, those schemes are not officially supported and may have issues in
interoperability with other tools\&.
Line 828, length 102
The NSS wiki has information on the new database design and how to configure
applications to use it\&.
Line 853, length 102
For information about NSS and other tools related to NSS (like JSS), check out
the NSS project wiki at
Line 854, length 140
\m[blue]\fBhttp://www\&.mozilla\&.org/projects/security/pki/nss/\fR\m[]\&;. The
NSS site relates directly to NSS code changes and releases\&.
Line 861, length 115
The NSS tools were written and maintained by developers with Netscape, Red Hat,
Sun, Oracle, Mozilla, and Google\&.
Line 863, length 86
Authors: Elio Maldonado <emaldona@redhat\&.com>, Deon Lackey
<dlackey@redhat\&.com>\&.
Line 866, length 170
Licensed under the Mozilla Public License, v\&. 2\&.0\&. If a copy of the MPL
was not distributed with this file, You can obtain one at
http://mozilla\&.org/MPL/2\&.0/\&;.
-.-.
Show if docman-to-man created this
4:.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
-.-.
Put a parenthetical sentence, phrase on a separate line,
if not part of a code.
See man-pages(7), item "semantic newline".
Not considered in a patch, too many lines.
pk12util.1:620:SHA\-1 and 40\-bit RC4 (\fB"PKCS #12 V2 PBE With SHA\-1 And 40
Bit RC4"\fR) (used by default for certificate encryption in non\-FIPS mode)
pk12util.1:657:SHA\-1 and 40\-bit RC2 (\fB"PKCS #12 V2 PBE With SHA\-1 And 40
Bit RC2 CBC"\fR)
pk12util.1:661:With PKCS #12, the crypto provider may be the soft token module
or an external hardware module\&. If the cryptographic module does not support
the requested algorithm, then the next best fit will be selected (usually the
default)\&. If no suitable replacement for the desired algorithm can be found,
the tool returns the error
-.-.
No need for "\&" to be in front of a period (.),
if there is a character in front of it
37:This documentation is still work in progress\&. Please contribute to the
initial review in
42:\fBpk12util\fR, enables sharing certificates among any server that supports
PKCS #12\&. The tool can import certificates and keys from PKCS #12 files into
security databases, export certificates, and list certificates and keys\&.
49:Import keys and certificates from a PKCS #12 file into a security database\&.
54:List the keys and certificates in PKCS #12 file\&.
59:Export keys and certificates from the security database to a PKCS #12 file\&.
66:Specify the key encryption algorithm\&.
71:Specify the certiticate encryption algorithm\&.
76:Specify the database directory into which to import to or export from
certificates and keys\&.
79:supports two types of databases: the legacy security databases (cert8\&.db,
80:key3\&.db, and
81:secmod\&.db) and new SQLite databases (cert9\&.db,
82:key4\&.db, and
83:pkcs11\&.txt)\&. If the prefix
85:is not used, then the tool assumes that the given databases are in the
SQLite format\&.
90:Specify the name of the token to import into or export from\&.
95:Specify the text file containing the slot\*(Aqs password\&.
100:Specify the slot\*(Aqs password\&.
105:Specify the desired length of the symmetric key to be used to encrypt the
private key\&.
110:Specify the hash algorithm used in the pkcs #12 mac\&. This algorithm also
specifies the HMAC used in the prf when using pkcs #5 v2\&.
115:Specify the desired length of the symmetric key to be used to encrypt the
certificates and other meta\-data\&.
120:Specify the nickname of the cert and private key to export\&.
122:The nickname can also be a PKCS #11 URI\&. For example, if you have a
certificate named "my\-server\-cert" on the internal certificate store, it can
be unambiguously specified as
"pkcs11:token=NSS%20Certificate%20DB;object=my\-server\-cert"\&. For details
about the format, see RFC 7512\&.
127:Specify the prefix used on the certificate and key databases\&. This option
is provided as a special case\&. Changing the names of the certificate and key
databases is not recommended\&.
132:Dumps all of the data in raw (binary) form\&. This must be saved as a DER
file\&. The default is to return information in a pretty\-print ASCII format,
which displays the information about the certificates and public keys in the
p12 file\&.
137:Enable debug logging when importing\&.
142:Specify the text file containing the pkcs #12 file password\&.
147:Specify the pkcs #12 file password\&.
446:for a token)\&.
458:# pk12util \-i /tmp/cert\-files/users\&.p12 \-d /home/my/sharednssdb
460:Enter a password which will be used to encrypt your keys\&.
462:and should contain at least one non\-alphabetic character\&.
477:command to export certificates and keys requires both the name of the
certificate to extract from the database (\fB\-n\fR) and the PKCS
#12\-formatted output file to write to\&. There are optional parameters that
can be used to encrypt the file to protect the certificate material\&.
487:# pk12util \-o certs\&.p12 \-n Server\-Cert \-d /home/my/sharednssdb
499:file are not human\-readable\&. The certificates and keys in the file can
be printed (listed) in a human\-readable pretty\-print format that shows
information for every certificate and any public keys in the
501:file\&.
511:# pk12util \-l certs\&.p12
515: Friendly Name: Thawte Freemail Member\*(Aqs Thawte Consulting (Pty)
Ltd\&. ID
527: Issuer: "E=personal\-freemail@thawte\&.com,CN=Thawte Personal
Freemail C
538:prints the certificates and then exports them into separate DER binary
files\&. This allows the certificates to be fed to another application that
supports
540:files\&. Each certificate is written to a sequentially\-number file,
beginning with
541:file0001\&.der
543:file000N\&.der, incrementing the number for every certificate:
549:pk12util \-l test\&.p12 \-r
552: Friendly Name: Thawte Freemail Member\*(Aqs Thawte Consulting (Pty)
Ltd\&. ID
561:Certificate Friendly Name: Thawte Freemail Member\*(Aqs Thawte
Consulting (Pty) Ltd\&. ID
569:PKCS #12 provides for not only the protection of the private keys but also
the certificate and meta\-data associated with the keys\&. Password\-based
encryption is used to protect private keys on export to a PKCS #12 file and,
optionally, the associated certificates\&. If no algorithm is specified, the
tool defaults to using PKCS #12 SHA\-1 and 3\-key triple DES for private key
encryption\&. When not in FIPS mode, PKCS #12 SHA\-1 and 40\-bit RC4 is used
for certificate encryption\&. When in FIPS mode, there is no certificate
encryption\&. If certificate encryption is not wanted, specify
573:option\&.
575:The private key is always protected with strong encryption by default\&.
577:Several types of ciphers are supported\&.
661:With PKCS #12, the crypto provider may be the soft token module or an
external hardware module\&. If the cryptographic module does not support the
requested algorithm, then the next best fit will be selected (usually the
default)\&. If no suitable replacement for the desired algorithm can be found,
the tool returns the error
662:\fIno security module can perform the requested operation\fR\&.
665:NSS originally used BerkeleyDB databases to store security information\&.
The last versions of these
677:cert8\&.db for certificates
688:key3\&.db for keys
699:secmod\&.db for PKCS #11 module information
702:BerkeleyDB has performance limitations, though, which prevent it from being
easily used by multiple applications simultaneously\&. NSS has some flexibility
that allows applications to use their own, independent database engine while
keeping a shared database and working around the access issues\&. Still, NSS
requires more flexibility to provide a truly shared security database\&.
704:In 2009, NSS introduced a new set of databases that are SQLite databases
rather than BerkleyDB\&. These new databases provide more accessibility and
performance:
714:cert9\&.db for certificates
725:key4\&.db for keys
736:pkcs11\&.txt, which is listing of all of the PKCS #11 modules contained in
a new subdirectory in the security databases directory
741:database type\&. The shared database type is preferred; the legacy format
is included for backward compatibility\&.
747:prefix with the given security directory\&. For example:
753:# pk12util \-i /tmp/cert\-files/users\&.p12 \-d dbm:/home/my/sharednssdb
775:~/\&.bashrc
776:file to make the change permanent\&.
786:https://wiki\&.mozilla\&.org/NSS_Shared_DB_Howto
799:https://wiki\&.mozilla\&.org/NSS_Shared_DB
805:has changed over time, while importing files exported with older versions
of NSS is still supported\&.
807:Until the 3\&.30 release,
809:used the UTF\-16 encoding for the PKCS #5 password\-based encryption
schemes, while the recommendation is to encode passwords in UTF\-8 if the used
encryption scheme is defined outside of the PKCS #12 standard\&.
811:Until the 3\&.31 release, even when
817:always used 256\-bit AES as the underlying encryption scheme\&.
821:accepts password\-based encryption schemes not listed in this document\&.
However, those schemes are not officially supported and may have issues in
interoperability with other tools\&.
828:The NSS wiki has information on the new database design and how to
configure applications to use it\&.
838:https://wiki\&.mozilla\&.org/NSS_Shared_DB_Howto
849:https://wiki\&.mozilla\&.org/NSS_Shared_DB
854:\m[blue]\fBhttp://www\&.mozilla\&.org/projects/security/pki/nss/\fR\m[]\&;.
The NSS site relates directly to NSS code changes and releases\&.
856:Mailing lists: https://lists\&.mozilla\&.org/listinfo/dev\-tech\-crypto
861:The NSS tools were written and maintained by developers with Netscape, Red
Hat, Sun, Oracle, Mozilla, and Google\&.
863:Authors: Elio Maldonado <emaldona@redhat\&.com>, Deon Lackey
<dlackey@redhat\&.com>\&.
866:Licensed under the Mozilla Public License, v\&. 2\&.0\&. If a copy of the
MPL was not distributed with this file, You can obtain one at
http://mozilla\&.org/MPL/2\&.0/\&;.
-.-.
Put a subordinate sentence (after a comma) on a new line.
42:\fBpk12util\fR, enables sharing certificates among any server that supports
PKCS #12\&. The tool can import certificates and keys from PKCS #12 files into
security databases, export certificates, and list certificates and keys\&.
80:key3\&.db, and
82:key4\&.db, and
85:is not used, then the tool assumes that the given databases are in the
SQLite format\&.
122:The nickname can also be a PKCS #11 URI\&. For example, if you have a
certificate named "my\-server\-cert" on the internal certificate store, it can
be unambiguously specified as
"pkcs11:token=NSS%20Certificate%20DB;object=my\-server\-cert"\&. For details
about the format, see RFC 7512\&.
132:Dumps all of the data in raw (binary) form\&. This must be saved as a DER
file\&. The default is to return information in a pretty\-print ASCII format,
which displays the information about the certificates and public keys in the
p12 file\&.
505:For example, this prints the default ASCII output:
536:Alternatively, the
540:files\&. Each certificate is written to a sequentially\-number file,
beginning with
543:file000N\&.der, incrementing the number for every certificate:
569:PKCS #12 provides for not only the protection of the private keys but also
the certificate and meta\-data associated with the keys\&. Password\-based
encryption is used to protect private keys on export to a PKCS #12 file and,
optionally, the associated certificates\&. If no algorithm is specified, the
tool defaults to using PKCS #12 SHA\-1 and 3\-key triple DES for private key
encryption\&. When not in FIPS mode, PKCS #12 SHA\-1 and 40\-bit RC4 is used
for certificate encryption\&. When in FIPS mode, there is no certificate
encryption\&. If certificate encryption is not wanted, specify
591:\fB"AES\-192\-CBC"\fR, and
661:With PKCS #12, the crypto provider may be the soft token module or an
external hardware module\&. If the cryptographic module does not support the
requested algorithm, then the next best fit will be selected (usually the
default)\&. If no suitable replacement for the desired algorithm can be found,
the tool returns the error
702:BerkeleyDB has performance limitations, though, which prevent it from being
easily used by multiple applications simultaneously\&. NSS has some flexibility
that allows applications to use their own, independent database engine while
keeping a shared database and working around the access issues\&. Still, NSS
requires more flexibility to provide a truly shared security database\&.
704:In 2009, NSS introduced a new set of databases that are SQLite databases
rather than BerkleyDB\&. These new databases provide more accessibility and
performance:
736:pkcs11\&.txt, which is listing of all of the PKCS #11 modules contained in
a new subdirectory in the security databases directory
739:Because the SQLite databases are designed to be shared, these are the
743:By default, the tools (\fBcertutil\fR,
759:To set the legacy database type as the default type for the tools, set the
789:For an engineering draft on the changes in the shared NSS databases, see
the NSS project wiki:
805:has changed over time, while importing files exported with older versions
of NSS is still supported\&.
809:used the UTF\-16 encoding for the PKCS #5 password\-based encryption
schemes, while the recommendation is to encode passwords in UTF\-8 if the used
encryption scheme is defined outside of the PKCS #12 standard\&.
811:Until the 3\&.31 release, even when
821:accepts password\-based encryption schemes not listed in this document\&.
However, those schemes are not officially supported and may have issues in
interoperability with other tools\&.
853:For information about NSS and other tools related to NSS (like JSS), check
out the NSS project wiki at
861:The NSS tools were written and maintained by developers with Netscape, Red
Hat, Sun, Oracle, Mozilla, and Google\&.
863:Authors: Elio Maldonado <emaldona@redhat\&.com>, Deon Lackey
<dlackey@redhat\&.com>\&.
866:Licensed under the Mozilla Public License, v\&. 2\&.0\&. If a copy of the
MPL was not distributed with this file, You can obtain one at
http://mozilla\&.org/MPL/2\&.0/\&;.
-.-.
Output from "test-groff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z
":
troff:<stdin>:464: warning: trailing space in the line
troff:<stdin>:465: warning: trailing space in the line
troff:<stdin>:466: warning: trailing space in the line
troff:<stdin>:488: warning: trailing space in the line
troff:<stdin>:489: warning: trailing space in the line
troff:<stdin>:513: warning: trailing space in the line
troff:<stdin>:550: warning: trailing space in the line
-.-.
Spelling:
certiticate ==> certificate
itegrity ==> integrity
-.-
Additionally (general):
Abbreviations get a '\&' added after their final full stop (.) to mark them
as such and not as an end of a sentence.
There is no need to add a '\&' before a full stop (.) if it has a character
before it!
