*use case:* '/openssl genpkey -genparam -algorithm DH/'
the '/genpkey/' doc's '*DH PARAMETER GENERATION OPTIONS'* section:
* first, before i forget -- again -- openssl's doc's should indicate that the
using the '-pkeyopt' option requires that the 'dh_paramgen_generator'
setting must precede the 'dh_paramgen_prime_len' if it is present or the
setting is ignored and results in a default setting of '2' (which could
stand to be mentioned as happening if the "generator" option is missing).
Moreover, it also might be useful to mention the default for "len" is '1024'
if the setting is missing.
* this section could use a note that the '-text' option appends the
PKCS#3-formatted data to the PEM-formatted data in the output. i am not
knowledgeable enough re PKCS-bound app's to be aware of where this
additional data might be required or if it is just a decade-old hold-over of
no current value.
* it also could be noted that '-outform' is ignored and the output default of
'PEM' rules (while possibly being followed by the PKCS#3 data, as
indicated). not everyone is aware that there is no such thing as a
DER-formatted file for DH param's.
***DH param file controls:*
now, the '-out' option creates a parameter file or the output goes to stdout if
missing. it is inconceivable that this option is not used in any automation mode
and barely likely that it would be missing in a CLI environment because that
would then require copying the stdout for insertion into some file. that leaves
the possibility of errors in manual edits and the CLI/script mode wherein the
stdout is '>' or '>>' to a file. obviously, '>>' or a language equivalent is an
appending blooper worth preventing because the new param set will be ignored if
a prior DH param set already exists in the file.
using the '-out' option is a not-so-strange 'special case' that openssl itself
has created. while not stated in the doc's, using this option will silently
over-write any pre-existent file and, thus, create a single-use file that can
only be used for the provision of custom DH param's: no other param's, key,
certs, or whatever that may have been present in the original file remain after
running in this mode.
because this openssl-created result is a user/developer expectation (i.e., an
openssl-established standard), it is reasonable to expect that openssl's
down-stream modules will enforce this standard and that is not happening. later
on, when the file is parsed, a search is made for the _*first*_ DH param set and
everything else before and after (no matter whether it is other valid PEM data,
a subsequent valid DH set, or just junk alpha-num lines) is completely ignored.
it is proposed that the openssl file-creation "standard" be enforced in all
modules. such enforcement would serve to guard against human error that can
creep into the file via manual edits and/or faulty scripting -- such as the
ages-old openssl snafu in openssl's own packages in the 'crypto/dh/dh2048.pem'
file which contains two (2) valid DH param sets and has been present in every
package version since at least 0.9.6. while we are mentioning this example, it
would prevent people from getting the wrong idea if the like-situated files
representing bit-lengths of 192, 512, and 1024 were removed since virtually all
current recommendations suggest starting at 2048 bits or more in 1024-bit steps.
the reason i have presented the need for further controls is because a
real-world case was brought to me by one of my former students who was testing
all the servers on his new job. he found that c. a third of the servers were
running under very-old and far-less-secure param's than they thought were in use
everywhere. we tracked it down to the same type of error that openssl itself
made, supra.
if nobody thinks it is a good idea for openssl to prevent mistakes such as this
happening and/or make clarifying additions to the doc's, there is no need to
make further reply to this thread.
--
Johann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160809/b06e586f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3825 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160809/b06e586f/attachment.bin>
