Eliot Lear <[email protected]> wrote: > but we need to know how to hook in. Specifically we're aiming to > provide the address of the resource directory, preferably in a way that > is signed by the registrar.
I feel that I'm missing some context, so let me repeat. You'd like to have a link to a resource directory, and you'd like to have it signed by registrar. I just want quibble slightly: while the registrar MAY be the CA, it isn't always directly the CA, it doesn't necessary have that kind of CA abilities. On the other hand, "signed by the registrar" could mean that it came through the (D)TLS connection from the Registrar, so maybe that's enough. In which case, let me repeat part of Max's response: max> Possibility-3) Introduce a followup REST message that the Pledge MAY use max> to obtain the configuration after s5.3.1 is complete. This allows the max> TLS connection to be maintained and optimizes the flow but keeps the max> distinct REST api calls from being overloaded. It is most consistent max> with section 5.7 and is probably the approach I’d prefer. Using max> persistent connections this is close to the optimization provided by 1 max> or 2 and allows for simpler handling on the Pledge. I definitely prefer that keeping up. I would suggest that a TLS resumption ticket be obtained and stored long term. -- 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
