Re: [Anima] about moving /.well-known/est/enrollstatus ??

["Fries, Steffen" <[e-mail]>]

> Sorry for the late replay on this. There is probably one fits all answer for this.
I definitely meant no single answer to 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.
After thinking twice about it and also rereading section 5.9.4 of BRSKI, I would suggest to also move enrollstatus to "/.well-known/brski/enrollstatus".
The reason for this is the following: 
- enrollstatus has been introduced to inform the registrar that the pledge confirms it has received the certificate and can use it.
- as stated in section 5.9.4 of BRSKI, enrollstatus can also be used to signal " attempted bootstrapping messages seen by the client". This is definitely an additional information not covered in existing certificate confirmation messages that the client at least tried enrollment but may not have been successful.
- The certificate confirmation messages defined in protocols like CMP and CMC are intended to also inform the CA, which would mean it is a message further forwarded by the registrar. This also means that additional information for the registrar, e.g., about enrollment attempts may not be contained in these messages.

Based on that the enrollstatus provides a value to the registrar independent of the enrollment protocol chosen. 

Best regards
Steffen




> 
> Best regards
> Steffen
> 
> > -----Original Message-----
> > From: Anima <[e-mail]> On Behalf Of Michael Richardson
> > Sent: Mittwoch, 16. September 2020 21:53
> > To: [e-mail]
> > 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
> >            Sandelman Software Works Inc, Ottawa and Worldwide
> >
> >
> >