[lamps] Re: Independent Crypto Review - Re: WG Last Call for draft-ietf-lamps-rfc4210bis and draft-ietf-lamps-rfc6712bis

[David Hook <[e-mail]>]

Hi, as this one is very close to my, and my employer's heart, I've just gone through it, with particular reference to the usage around the new KEM algorithms.

Short of actually trying to fully implement it, it looks good.

This might sound odd, but I was particularly impressed with one line in Section 5.1.1. "If a server receives such request with a missing transactionID field, then it MUST populate the transactionID field if the message contains a KemCiphertextInfo field." after checking all the usages of transactionID I realized it really was a case of a few well placed words closing the door on whole set of possible incompatibility issues - it certainly makes sense for the client to not set a transactionID in this case, so the server should allow for it, likewise, having granted the client an indulgence, the server needs to be sure the conversation continues in a more constrained fashion.

Looking forward to actually implementing it fully.

Regards,
David


David Hook

VP Software Engineering

Crypto Workshop

-

M: [phone]

[e-mail]<https://www.keyfactor.com/>


[cid:c5041310-4cd8-4d01-9654-6d95c548c888]

Identity-first security for every device,
workflow, and thing.

Follow Keyfactor on LinkedIn<https://linkedin.com/company/wearekeyfactor/>

CONFIDENTIALITY NOTICE

This communication may contain privileged or other confidential information. If you received this email in error, then please advise the sender by reply email and immediately delete the message and any attachments  without copying or disclosing the contents. Thank you.