Michael Richardson <[email protected]> wrote:
>Yanlei\(Ray\) <[email protected]> wrote:
> > I would like to ask for the a time slot for my new individual draft.
> > Topic/Title: BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI
>
>Thank you for your document. I look forward to your slides for further
>explanation.
>
>1. It seems that you've missed much of the Raw Public Key support that is a
>key part of constrained-BRSKI.
The Raw Public Key is used by the voucher before the "enroll" state as defined
in constrained-BRSKI.
The BRSKI-CLE is designed for the "enroll" state after the "imprint" state.
+------v-------+
| (4) Imprint |
+------+-------+
| send Voucher Status Telemetry
+------v-------+
| (5) Enroll |
+------+-------+
Thus, BRSKI-CLE is not involved in the vouchers.
This draft focuses on the enrollment phase in BRSKI and the authentication for
the communication between pledges after enrollment.
>2. Do you have a proof-of-concept implementation?
We have some implementations on certificateless authentication but not on
BRSKI-CLE.
>3. There seems to be a significant gap in how the vouchers would work.
>I didn't understand this at all.
As explaining in the first question, BRSKI-CLE is not involved in the vouchers.
>It all starts with an unsupported assumption that IoT devices can not hold
>certificates. Yet, they are being installed into devices by the billions
>today.
If the enrollment protocol issues a domain certificate to the IoT devices,
after the enrollment, the IoT devices just can use the domain certificate for
authentication in communication.
BRSKI-CLE is an enrollment protocol that issues a credential, instead of
certificates, based on public keys to the IoT devices.
Thus, the IoT devices can use the credential to authenticate each other in
communication after enrollment.
BRSKI-CLE provides a lightweight way for the authentication between IoT devices
in communication after enrollment.
BRSKI-CLE does not change any process before the "enroll" state in BRSKI.
Thus, BRSKI-CLE also supports an X.509 IDevID certificate installed by the
vendor on IoT devices.
The IoT devices only need to bootstrap once and may do mutual communications
unlimited times after enrollment.
Therefore, it doesn't matter to use certificates in bootstrapping.
A lightweight authentication protocol for communication after bootstrapping is
more meaningful.
--
Best regards,
Lei YAN
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
