Max, While implementing pure enrollment code for EST-COAP testing, I have realized that on the Registrar there is a state which we may not have adequately discussed.
While 2.1 provides a nice diagram for the Pledge, when we changed the view of things we lost some of the state machine thoughts from the Registrar point of view. For a pure first-time enrollment, there is not a lot of issue. The issue comes when one tries to combine a few functions in a registrar. (BTW: I had advocated splitting these into seperate servers and ports) When a registrar receives a connection from another node, it examines the TLS Client Certificate and may categorize it into three possible things: 1) This is an LDevID certificate (possibly recently expired, see LAMPS), and the node is about to as for a simpleenrollment to renew it! 2) This is an IDevID certificate from a manufacturer which implements BRSKI (and which is in the whitelist) and which is expected to do voucher processing. 3) This is an IDevID certificate from a manufacturer/device which has a known anchor, just does EST enrollment, and already trusts the Registrar via "magic". Part of my surprise was that I realized that the TLS connection is never really "provisional" from the Registrar point of view. It's either authenticated by the IDevID/manufacturer-certificate, or via the LDevID. Or the client certificate does not lead to any reasonable trust anchor, and the connection is to be rejected. Unless the Registrar is "promiscuous", which is to say has a "*" in the anchor whitelist. It seems to me that like we either ought to fail the TLS connection in a very clear fashion if the client certificate is unacceptable, or we need to have a very clear 5xx return to all operations if we think it's a good idea to let the connection persist. (Caveat, we might actually want to log the telemetry status operation, and perhaps we always return 200 for that) -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
