Figure 3 "verify audit log" needs to be done before enrollment

[EskoDijk]

Typically after the Registrar gets the Voucher, and before doing enrollment, it needs to request the audit-log to MASA to help in making the decision (to enroll the new device, or not).

In RFC 8995 this is done after receiving the Pledge's voucher status response i.e. if the Voucher is accepted by the Pledge.

In PRM this isn't possible, so the Registrar needs to request I think the audit-log right after getting the Voucher from MASA.

This way, the decision whether to enroll the device or not can be based on its history.

Suggestion is to update Fig 3 for this.

[stfries]

In general I would agree to Esko's observation, although the registrar would not have the voucher telemetry from the pledge. But it needs to perform the verification of the audit log before further processing the enrollment request. @mcr, could you double check? If solved, also consider issue #54

[EskoDijk]

From what I see in 8995, the MASA is ready to provide the (updated) audit log as soon as the voucher has been provided (Fig 4 in 8995). So the Registrar can then check this right after it gets the Voucher. If the Registrar needs to check the audit-log again after getting the Pledge's voucher telemetry, the Registrar can just do that. It could even repeat the request again during the 2nd check, as significant time may have passed (e.g. days, weeks, ...) since the first check.

At that point in time (when doing the 2nd check), the Registrar has both the Pledge's voucher telemetry and enrollment telemetry info so it may be that the Pledge is already enrolled. If the Registrar at this point in time decides that the Pledge is for security reasons or so unwanted into the Domain, I guess the only thing it could do is revoke the certificate?

[stfries]

Agreed regarding the audit log from the MASA. If the registrar for whatever reason needs to drop the pledge, it would do so by revoking the certificate. I would add this to section 5.5.4 as new part:

According to RFC8995 section 5.9.4, the registrar SHOULD respond with an HTTP 200 in the success case or fail with HTTP 4xx/5xx codes as defined by the HTTP standard. Based on the failure case the registrar MAY decide that for security reasons the pledge is not allowed to reside in the domain. In this case the registrar MUST revoke the certificate.** The registrar-agent may use the response to signal success / failure to the service technician operating the registrar agent. Within the server log the registrar SHOULD capture this telemetry information.

[mcr]

In general I would agree to Esko's observation, although the registrar would not have the voucher telemetry from the pledge. But it needs to perform the verification of the audit log before further processing the enrollment request. @mcr, could you double check? If solved, also consider issue #54

In PRM, I think that the Registrar is going to provide a certificate to the Registrar-Agent at the same as it provides the voucher. So, if the Registrar is going to examine the audit-log, it needs to do that before it issues the certificate, and yes, that would be before it knows if the pledge has accepted the voucher.

I don't really believe in revocation :-) But, I agree that the Registrar has to do that. I think that there is probably a needed signal from the Registrar to Registrar-Agent that the pledge was rejected, and needs to go through a factory-reset/re-enrolment attempt. This will be an annoying for the installers, so it needs to be batched.

[stfries]

@mcr, do you think we need further text on the issue? The signal back to the registrar-agent is already described and how to deal with the failure is more or less a policy decision of the operator.

[stfries]

Included the text as proposed: "Based on the failure case the registrar MAY decide that for security reasons the pledge is not allowed to reside in the domain. In this case the registrar MUST revoke the certificate."