[krbdev.mit.edu #7596] [Comment] PKINIT should allow missing DH param Q
"Greg Hudson via RT" <[email protected]> Sat, 16 Oct 2021 10:49:24 -0400
| Newsgroups | gmane.comp.encryption.kerberos.bugs |
|---|---|
| Message-ID | <rt-4.4.3-2-582344-1634395764-1076.7596-8-0@kerborg-prod-app-1.mit.edu> |
http://kerborg-prod-app-1.mit.edu/rt/Ticket/Display.html?id=7596 This is a comment. It is not sent to the Requestor(s): Ticket 8398 (commit e5c77a11341a79e6af1e5aef7c587a5b75a9e378, "Add PKINIT support for OpenSSL 1.1.0", going into release 1.15) attempted to preserve this workaround using a custom ASN.1 type with an optional q parameter. However, the same commit added a helper dup_dh_params() with error-checking on the results of BN_dup(), replacing the old code which had no error-checking. This error-checking would erroneously trigger if q is unset in the DH parameters, causing server_process_dh() and therefore pkinit_server_return_padata() to return ENOMEM. Since no one has reported the regression to my knowledge, I would guess that Microsoft fixed its bug and the workaround is no longer needed. I have asked Microsoft dochelp for clarification of which versions omit the q value. If we need to restore the workaround, dup_dh_params() can check for (oldq != NULL && q == NULL) instead of q == NULL. Also, we could do the parsing more simply in OpenSSL 1.1 by trying d2i_DHxparams() and falling back to d2i_DHparams(). The latter function will read domain parameters using the PKCS#3 DHParameter type, which has no q value. (OpenSSL 1.0 does not have DHxparams support, so we're stuck with custom encoding and decoding to handle the RFC 3279 type.)