with RPK, how does the Pledge validate the Registrar in the future?

[mcr]

XXX - how does the Pledge validate the Registrar in the future?

[EskoDijk]

I assume this is for the case that the constrained Pledge cannot do X.509 cert chaining operations?

Because if it can do that, it can verify any future Registrar, by checking its chaining of the Registrar cert to the Domain CA and verifying that Registrar has the 'cmcRA' flag set. (The Pledge will obtain at least one trust anchor of the domain being a Domain CA certificate during combined BRSKI/EST. )

If it cannot do chaining operations, I don't see a way to validate a future Registrar apart from bootstrapping again. (Requires some trigger to re-bootstrap - currently not in the protocol. Difficult issue also because it needs to be someone with a proven authorization to issue a "re-bootstrap" command i.e. a formal admin/commissioner role.)

One thing a minimal Pledge could do is keep the pinned Registrar RPK stored as a trust anchor. So that in the future it can at least re-enroll using the same Registrar again. Would it be okay ? Guess not? It goes against the concept we discussed that the pinned Registrar identity is only valid for the duration of the initial bootstrap process. After this, the Domain CA takes over.

[EskoDijk]

Update based on discussion in the call:
if a Pledge (unable to do chaining operations) needs to validate the Registrar / a Registrar in the future, the only thing it can do is redo the bootstrap. This means that also re-enroll (renew/rekey) operations are not supported for that Pledge; it will always have to use BRSKI bootstrap plus EST enroll. We discussed that this could be okay for a particular class of IoT devices e.g. ones that change owner/user very often and they need to be enrolled into the domain of the owner/user.

[EskoDijk]

After looking at the PR text and the previous comments again, my overall conclusion is that I support including such a section in our draft. It does not radically change our constrained-BRSKI model - it is just a new variant of it of the "most constrained" category.

But the text requires some major work still, I think:

• the proposed approach is in fact not at all related to RPK use for 'proximity-registrar' and for 'pinned-registrar' . It could be applied identically when full certificates are used. Of course using only the RPKs leads to smaller size for Voucher and VR.
• For above idea of using "full certificate" this means the Pledge just captures the X.509 Registrar leaf cert as a binary blob from the DTLS handshake.
  • It doesn't parse it except as needed for the public/private key validation in the handshake.
  • It does not verify the chain in the DTLS handshake because it can't do PKIX path validation. The MASA does the chain validation instead before issuing the voucher!
  • (It would not make sense in my view to have the path validation present in the DTLS stack code on the Pledge, but not use this for the path validations needed for constrained-BRSKI/EST-coaps as we define it.)
• Similarly for above idea of using "RPK only" the Pledge captures the Registrar cert and extracts/parses the Public Key out of it. Then it puts this in the field proximity-registrar-pubk.
• The MASA will create a Voucher that pins the exact binary blob (either cert or RPK) that the Pledge included as 'proximity-Registrar'.
• The Pledge can just binary-compare the pinned entity to the proximity entity that it sent, and if equal, then it can trust the Registrar.
• we can say EST re-enrollment is not possible in this case because that would imply trusting the same Registrar again in some time (e.g. a year later) using a trust anchor from the Voucher which is supposed to be only temporary!
• agree that our text can say that the MASA may include additional trusted-entities in the Voucher (nice idea), but not further defined in our document.
• we can also consider a Pledge that enrolls and never needs to talk to any server/entity in the Domain itself so it will basically trust no-one there. Maybe it is a sensor that only reports to the cloud in a secure way, so it will only trust its phone-home cloud server for connections until the end of its life. (We might even have text indicating this possibility. Makes this solution look more useful :) )

[EskoDijk]

And a note to us authors that we could reference Appendix D.1 "Minimal Pledge" which seems to fit the described Pledge very well. The section name for this ought to be changed to "Look ma, no PKIX operations!" but unsure whether the RFC editors apply any criteria of gender-neutrality in that case.