[krbdev.mit.edu #8642] etype-info conflated for initial, final reply key enctype

[Greg Hudson via RT]

It looks like I was wrong about #3.  get_in_tkt.c resets ctx->etype 
to the AS-REP enctype before processing the final padata list, 
although it can then be changed by etype-info in the AS-REP.  The 
PKINIT client will use the correct enctype unless the KDC sends 
etype-info with a different enctype (which would be in violation of 
RFC 4120).  For robustness it would be better to use the AS-REP 
enctype, but there's no immediate bug, and KDCs can omit etype-info 
in PKINIT AS-REPs.

The get_etype() callback has some history to it.  In release 1.6 when 
it was first added (in the form of a get_data_proc request), it 
always yielded the AS-REP enctype, or failed with ENOENT if there was 
no AS-REP yet.  The implementation of FAST in 1.7 (ticket 6436) 
changed the callback to the current behavior and used it in encrypted 
challenge.  Ticket 6976 added the get_as_key() callback and stopped 
using get_etype() in encrypted challenge, so only PKINIT currently 
uses the callback.  But the callback is now documented as returning 
the enctype from etype-info before the AS-REP, so we shouldn't 
completely revert to the 1.6 behavior.