Fries, Steffen <[email protected]> wrote: >> 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".
haha. I see that I now actually mis-read your first email to mean the
second one.
> - 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.
yes, that is where we cared.
We knew that if it failed, that we'd want as much information as possible r=
eturned.
If a truck roll is required (in a DC/ISP situation), the information in the
failure message would be important in deciding if it was junior remote-hands
that would just power the system to try again, or if someone more senior
needs to go.=20
> - 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.
The enrollment_status message could be extended to include CMP information.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
