I'm sorry- the subject is wrong. The IMCK derivation IS clear. This is
related solely to Request-Action (doh!).
On 10.03.23 17:17, Eliot Lear wrote:
Hi Joe,
First and foremost, I'd like to again thank Alan for taking this on.
Second, because I expect to have a few comments, to keep them
separate, I'll start different threads.
In Section 4.2.9, the beginning text reads:
The Request-Action TLV MAY be sent by both the peer and the server in
response to a successful or failed Result TLV.
I believe this text is overly restrictive, and should be relaxed to say:
The Request-Action TLV MAY be sent by both the peer and the server.
The reason for this is as follows: if the server notices that the
client certificate is expiring, or if the server otherwise has need of
the client renewing its certificate early (say due to impending change
to trust anchors), the server should be able to issue a Request-Action
TLV upon successful TLS hellos, without the need for a Result or
Intermediate-Result frame.
Thanks,
Eliot
On 10.03.23 16:58, Joseph Salowey wrote:
This is the working group last call for draft-ietf-emu-rfc7170bis-05
[1]. Please review the draft and send comments to the list or open
issues in GitHub [2]. Further discussion on the open issues will be
considered as part of the last call. The last call ends March 24,
2023. The chairs would appreciate earlier reviews so we can plan to
resolve issues during our Monday meeting on the 27th.
Thanks,
Peter and Joe
[1] https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis
[2] https://github.com/emu-wg/rfc7170bis/issues
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
