On Dec 11, 2018, at 3:16 PM, Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca>> wrote:
Jim Schaad <i...@augustcellars.com<mailto:i...@augustcellars.com>> wrote: Clarification requested - exactly what element is the Registrar? It's an EST RFC7030 term, but essentially it's the server that connects to (or is) the CA. The Registrar terminology is from the Anima working group and is closely analogous to the “Registration Authority” we know and love from the PKI space. Join Registrar (and Coordinator): A representative of the domain that is configured, perhaps autonomically, to decide whether a new device is allowed to join the domain. The administrator of the domain interfaces with a "join registrar (and coordinator)" to control this process. Typically a join registrar is "inside" its domain. For simplicity this document often refers to this as just "registrar". Within [I-D.ietf-anima-reference-model<https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-17#ref-I-D.ietf-anima-reference-model>] this is refered to as the "join registrar autonomic service agent". It terminates the BRSKI protocol from the new device and, after processing and decisions, forwards messages to a manufacturer authorized signing authority to obtain vouchers and ensure records/audit-logs are kept. It also pulls those audit logs to make additional decisions. It is responsible for making the authorization decision concerning if the new device should be allowed to join the network. It also optionally doubles as a enrollment over secure transport (RFC7030) registration authority in the normal PKI sense. This is recommended in that BRSKI recommends that devices go on to enroll and obtain a certificate. - max The one item that I can generally think of that might be a problem is that the answers to /att and /crts may differ based on the entity that is asking the question. In this case not having the entity being validated means that the "wrong" answer may be returned or different answers would be returned before and after validation. Yes, I agree: it should be restricted. I think that it should be restricted. Partly, I'm just not sure where the text should go, or if it needs to be said at all. -- Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca>>, Sandelman Software Works -= IPv6 IoT consulting =-
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
