[client] pqkem: document the real responder callback timing

OnNewPSKReady's doc claimed the responder fires it "on receiving the confirm",
but there is no confirm round: the responder fires it right after deriving the
PSK from the offer and before sending the answer. Say so, so a host does not
assume the peer has already confirmed the key.

Found in cubic review on #7098 (client/internal/pqkem/callbacks.go:11).
This commit is contained in:
riccardom
2026-10-07 13:23:22 +02:00
parent 9af27883df
commit cc2d43ee09
+5 -3
View File
@@ -6,9 +6,11 @@ package pqkem
// the KEM code be extracted as a standalone library.
type CallbackHandler interface {
// OnNewPSKReady fires when a fresh post-quantum PSK has been derived for a peer
// and must be programmed into the consumer's secure channel. It is invoked at
// the commit point of each side: the initiator on receiving the answer, the
// responder on receiving the confirm.
// and must be programmed into the consumer's secure channel. The protocol has no
// explicit confirm: the initiator fires it on receiving the answer, the responder
// fires it right after deriving the PSK from the offer and before sending that
// answer. A fired callback therefore means the key is derived locally, not that the
// peer has confirmed it — the next offer is the later acknowledgement.
OnNewPSKReady(remoteID RemoteID, psk PSK) error
// OnRekeyFailed fires when an exchange fails to converge within the allotted