Closed mcr closed 1 year ago
I do not see a problem here in comparison with BRSKI, while I do not know for BRSKI-PRM.
Figure 3 just extends/generalizes the final (enrollment) step of BRSKI.
RFC 8995, Section 5.9: EST Integration for PKI Bootstrapping says:
The pledge SHOULD follow the BRSKI operations with EST enrollment operations including "CA Certificates Request", "CSR Attributes Request", and "Client Certificate Request" or "Server-Side Key Generation", etc.
This is also done with BRSKI-AE, in a fashion that is independent of EST but essentially with the same abstract contents (where part of these, namely /cacers, and /csrattrs are optional, like in EST).
BTW, note that the optional certificate confirmation mentioned in Figure 3 is not available in EST, but in CMP, and this type of confirmation is specific to the enrollment step and independent of the final BRSKI-side Enrollment Status Telemetry, as described in RFC 8995, Section 5.9.4: Enrollment Status Telemetry. Maybe this subtle difference should be pointed out.
Hi @mcr, we just noticed this rather dated open issue. Can it be closed meanwhile? If so, I'd ask you to do that.
In section 4.2, figure 3, the time sequence diagram has the steps 1,2, which does not fit into the BRSKI RFC8995 flow, nor does it seem to fit into the PRM model of communications. Specifically, the CA Certs Request/reply occurs after enrollment, I think, but I guess it just occurs after voucher response. The Attribute Request/Response is I guess the same as the /csrattrs request. The Certificate Confirm step seems fine. Mostly, I am concerned that this is not synchronized with PRM's needs.