Hi Michael, Sorry for the late replay on this. There is probably one fits all answer for this. The reason is that the enrollment protocols are defined different in that respect. - EST does not provide it out of the box, this was the reason to have it in BRSKI - CMP provides a certificate confirmation message (certConf). - CMC provides a confirmation message with the Confirm Certificate Acceptance Control - SCEP explicitly mentions the lack of the certificate confirmation message in the security consideration section - ACME seems to not provide it either.
Given that it would make sense to move it to /brski to make it independent from EST. Contrary, BRSKI-AE that would benefit from the /est to /brski change by making the enrollment protocol choice independent form the voucher exchange builds on authenticated self-contained objects (signature wrapped objects). These are currently supported by EST with fullcmc, CMP, and CMC. SCEP from my understanding does not support enrollment using a certificate from a different issuing CA. It supports reenrollment using the existing certificate but not initial enrollment as the IDevID would be issued from a different CA. That was at least my understanding by reading section 2.3 of SCEP. Based on the assumption that CMP and CMC provide the signature wrapping without limitations and also support certificate confirmation messages, it seems to be only applicable to EST (simpleenroll or fullcmc). That would rather indicate to keep "/.well-known/est/enrollstatus" as is. Best regards Steffen > -----Original Message----- > From: Anima <[email protected]> On Behalf Of Michael Richardson > Sent: Mittwoch, 16. September 2020 21:53 > To: [email protected] > Subject: [Anima] about moving /.well-known/est/enrollstatus ?? > > > One of the changes in the diff that I thought I had raised, but got no > discussion > was enrollstatus. > > There are two telemetry status reports that BRSKI added .. "to EST". > The first is the /.well-known/est/voucher_status. This is a report on whether > the > voucher was acceptable. This is entirely RFC8366/BRSKI content, and is > completely independant of the certificate enrollment protocol. It should > change > to /.well-known/brski/voucher_status. > > The second one, described in section 5.9.4 is about whether or not the > certificate was enrolled correctly. This provides feedback about whether or > not the new certificate was retrieved and installed correctly. > > It says to use the new certificate and report. > It's not that interesting when there is success. > > It's more interesting when there is a failure of some kind. > As such, it is unclear to me if this is tied up in EST only, or whether this > is really a > BRSKI thing. > It's not BRSKI/RFC8366 that failed, it's EST/CMP/SCEP/pixie-dust that failed. > > It seems that moving it to /brski is acceptable, but it might be that it > should > remain in /est. I am not steeped in the art of CMP or SCEP or ???, so I don't > know if what we've done for EST will translate well. > > I do not feel strongly either way, but in the diff I left a ?XXX because I > didn't > know. > I am sorry to bring this up during the IETF last-call: I think that I just > need some > confirmation from CMP experts that we aren't creating something that is > unimplementable. > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
