Reset the corresponding slot in requester context after a SetCertficate command execution

[xiangfeima]

After new certificate chain is set to Responder by SetCertificate command, previously retrieved digest and certificate chain data of this slot remain in Requester's context. Further KeyExchange using same slot as param2 in the request would be failed.

I'm wondering if it's better to reset the corresponding slot in requester context (including responder slot mask) after a SetCertficate command execution. So further commands using this same slot for signature verification (such as KeyExchange) can be detected to be failed in earlier stage by check the given slot with responder slot mask or somehow (that also suggests user should do a GetDigests/GetCertificate before using the slot just has new certificate chain set to responder), rather than current that the failure would be detected until signature verification failed from the received response.

[steven-bellock]

This has overlap with #873.

The proposal sounds reasonable.

[xiangfeima]

Looks #873 is talking about populating the spdm context with the new certificate on Responder side. Would you share the further plan about this one and #873? I saw it is out there for few months :P

[jyao1]

11/7/2022 - this can be done before Q1'2023.

[xiangfeima]

@steven-bellock I would take this.

[xiangfeima]

Hi @jyao1 @steven-bellock, from my first attempt to fix this, I found currently the peer_digest_slot_mask in context would never be used after it is set by get_digests() process. Instead we pass slot_mask to user. https://github.com/DMTF/libspdm/blob/f59b5cb1a229184f85f80fe525b4d670c0516af8/include/library/spdm_requester_lib.h#L104-L105 Now I think that the initial proposal

reset the corresponding slot in requester context (including responder slot mask) after a SetCertficate command execution So further commands using this same slot for signature verification (such as KeyExchange) can be detected to be failed in earlier stage by check the given slot with responder slot mask or somehow ...

may not be that necessary.

If we change it to that libspdm resets the requester context after a set_certificate, there would be a gap between libspdm and Integrator, since for now we don't have an appropriate mechanism, say to notify Integrator that the context is reset, then the event can be hooked to a get_digests/get_certificate execution. Though this can be solved by adding a callback function to set_certificate, I just think if that went too far.

Comparing with above, if we keep the idea to leave the action to Integrator to update the digests and certificate after a set_certificate, it seems that we don't need a fix or enhancement here. (Maybe we just document that after a set_certificate, Integrator may need to update this slot by get_digests/get_certificate).

What do you think?

[steven-bellock]

That sounds reasonable as well.

[xiangfeima]

Thank you, let's close this.