use case: 'openssl genpkey -genparam -algorithm DH'
the 'genpkey' doc's 'DH PARAMETER GENERATION OPTIONS'
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
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.