During a PKINIT AS-REQ, there are two rounds of client padata processing, one to generate the request and one to validate the KDC response and compute the reply key.<br />
<br />
During the first round,&nbsp;pkinit_client_prep_questions() calls&nbsp;pkinit_identity_initialize(), which calls&nbsp;crypto_load_certs() with&nbsp;defer_id_prompts=TRUE.&nbsp; This accumulates a list of identities in&nbsp;id_cryptoctx-&gt;deferred_ids.&nbsp; pkinit_client_prep_questions () then generates a PKINIT question containing the list of identities to be prompted for.<br />
<br />
During the second round, pkinit_client_prep_questions() is again called.&nbsp; The pkinit_identity_initialize() call is skipped (because&nbsp;reqctx-&gt;identity_initialized is true), but the list of deferred identities is still present, so a question is again generated.&nbsp; PKINIT does not need access to client certificates while processing the KDC response, so the question is pointless and creates a bad user experience.<br />
<br />
The simplest way to to suppress the second question is probably to check that the padata type is KRB5_PADATA_PK_AS_REQ.<br />
<br />
The double-responder behavior is already visible in t_pkinit.py tests, such as the &quot;FILE identity, password on key (responder)&quot;.&nbsp; We simply need to count the number of &quot;OK:&quot; messages in the output to see how many responder calls are made.<br />
<br />
Reported by&nbsp;Russ Allbery.