These comments are on the version of the specification released on Monday 2019-02-11 at https://www.openssl.org/docs/OpenSSL300Design.html General notes on this release: - The release was not announced on the openssl-users and openssl-announce mailing lists. A related blog post was announced two days later. - The related strategy document is at https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html (This link is broken on the www.openssl.org front page). - The draft does not link to anywhere that the public can inspect archived or version tracked document versions. Non-FIPS architecture issues: - The identifiers for predefined parameters and values (such as "fips", "on", "off", "aes-128-cbc" should be binary values that cannot be easily searched in larger program files (by attackers). This rules out both text strings, UUID values and ASN OID values. Something similar to the function ids would be ideal. Note that to make this effective, the string names of these should not appear in linked binaries. (The context of this is linking libcrypto and/or libssl into closed source binary programs, since open source binaries cannot hide their internal structure anyway). - It should be possible for applications to configure OpenSSL to load provider DLLs and config files from their own directories rather than the global well-known directory (isolation from system wide changes). - It should be possible for providers (possibly not the FIPS provider) to be linked directly into programs that link statically to libcrypto. This implies the absence of conflicting identifiers, a public API to pass the address of a |OSSL_provider_init|function, all bundled providers provided as static libraries in static library builds, and a higher level init function that initializes both libcrypto and the default provider. - Static library forms of the default provider should not force callers to include every algorithm just because they are referenced from the default dispatch tables. For example, it should be easy to link a static application that uses only AES-256-CBC and SHA-256, and contains little else. Such limited feature applications would obviously have to forego using the all-inclusive high level init function. - For use with engine-like providers (such as hardware providers and the PKCS#11 provider), it should be possible for a provider to provide algorithms like RSA at multiple abstraction levels. For example, some PKCS#11 hardware provides the raw RSA algorithm (bignum in, bignum out) while others provide specific forms such as PKCS#1.5 signature. There are even some that provide the PKCS#1.5 form with some hashes and the RSA form as a general fallback. - Similarly, some providers will provide both ends of an asymmetric algorithm, while others only provide the private key operation, leaving the public key operation to other providers (selected by core in the general way). - The general bignum library should be exposed via an API, either the legacy OpenSSL bignum API or a replacement API with an overlap of at least one major version with both APIs available. - Provider algorithm implementations should carry description/selection parameters indicating limits to access: "key-readable=yes/no", "key-writable=yes/no", "data-internal=yes/no", "data-external=yes/no" and "iv-internal=yes/no". For example, a smartcard-like provider may have "key-readable=no" and "key-writable=yes" for RSA keys, while another card may have "key-writable=no" (meaning that externally generated keys cannot be imported to the card. "data-internal" refers to the ability to process (encrypt, hash etc.) data internal to the provider, such as other keys, while "data-external" refers to the ability to process arbitrary application data. - Variable key length algorithm implementations should carry description/selection parameters indicating maximum and minimum key lengths (Some will refuse to process short keys, others will refuse long keys, some will require the key length to be a multiple of some number). - The current EVP interface abuses the general (re)init operations with omitted arguments as the main interface to update rapidly changing algorithm parameters such as IVs and/or keys. With the removal of legacy APIs, the need to provide parameter changing as explicit calls in the EVP API and provider has become more obvious. - A provider property valuable to some callers (and already a known property of some legacy APIs) is to declare that certain simple operations will always succeed, such as passing additional data bytes to a hash/mac (the rare cases of hardware disconnect and/or exceeding the algorithm maximums can be deferred to "finish" operations). A name for this property of an algorithm implementation could be "nofail=yes", and the list of non-failing operations defined for each type of algorithm should be publicly specified (a nofail hash would have a different list than a no-fail symmetric encryption). - Providers that are really bridges to another multi-provider API (ENGINE, PKCS#11, MS CAPI 1, MS CNG) should be explicitly allowed to load/init separately for each underlying provider. For example, it would be bad for an application talking to one PKCS#11 module to run, load or block all other PKCS#11 modules on the system. - Under normal file system layout conventions, /usr/share/ (and below) is for architecture-independent files such as man pages, trusted root certificates and platform-independent include files. Architecture specific files such as "openssl/providers/foo.so" and opensslconf.h belong in /usr/ or /usr/local/ . FIPS-specific issues: - The checksum of the FIPS DLL should be compiled into the FIPS- capable OpenSSL library, since a checksum stored in its own file on the end user system is too easily replaced by attackers. This also implies that each FIPS DLL version will need its own file name in case different applications are linked to different libcrypto versions (because they were started before an upgrade of the shared libcrypto or because they use their own copy of libcrypto). - If possible, the core or a libcrypto-provided FIPS-wrapper should check the hash of the opensslfips-3.x.x.so DLL before running any of its code (including on-load stubs), secondly, the DLL can recheck itself using its internal implementation of the chosen MAC algorithm, if this is required by the CMVP. This is to protect the application if a totally unrelated malicious file is dropped in place of the DLL. - The document seems to consistently only mentions the shortest/weakest key lengths, such as AES-128. Hopefully the actual release will have no such limitation. - The well-known slowness of FIPS validations will in practice require the FIPS module compiled from a source change to be released (much) later than the same change in the default provider. The draft method of submitting FIPS validation updates just before any FIPS-affecting OpenSSL release seems overly optimistic. - Similarly, due to the slowness of FIPS validation updates, it may often be prudent to provide a root-cause fix in the default provider and a less-effective change in the FIPS provider, possibly involving FIPS-frozen workaround code in libcrypto, either in core or in a separate FIPS-wrapper component. - The mechanisms for dealing with cannot-export-the-private-key hardware providers could also be used to let the FIPS provider offer algorithm variants where the crypto officer (application writer/installer) specify that some keys remain inside the FIPS blob, inaccessible to the user role (application code). For example, TLS PFS (EC)DHE keys and CMS per message keys could by default remain inside the provider. Extending this to TLS session keys and server private key would be a future option. - In future versions, it should be possible to combine the bundled FIPS provider with providers for FIPS-validated hardware, such as FIPS validated PIV smart cards for TLS client certificates. - Support for generating and validating (EC)DH and (EC)DSA group parameters using the FIPS-specified algorithms should be available in addition to the fixed sets of well-known group parameters. In FIPS 800-56A rev 3, these are the DH primes specified using a SEED value. Other versions of SP 800-56A, and/or supplemental NIST documents may allow other such group parameters. - If permitted by the CMVP rules, allow an option for application provided (additional) entropy input to the RNG from outside the module boundary. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
