Having read through the emails and reviewed the document a bit more, I think that I see some ways in which the document could be clarified.
First, this is not an extension or amendment to BRSKI.
BRSKI is a way to introduce trust between Pledges and Registrars via the
third-party RFC8366 voucher. In 8995, it results in a RFC7030 *EST* channel,
which is literally... "Enrollment over Secure Transport".
RFC7030 defines a CSR-based method to get a new certificate.
CLE is not about BRSKI at all, it's about a new kind of enrollment.
So, this document should be "EST-CLE", which is much akin to "BRSKI-AE"
(which arguably from this point of view, should be "EST-AE" or even
"EST-CMP", only it's not EST at all)
The reason CMP changes BRSKI is because it does away with the (provisional)
TLS connection, and RFC8995 deals primarily with how that connection is setup
to be be useful.
From what I can see, BRSKI-CLE does nothing to the provisional-TLS connection
at all, but rather changes what occurs after the Secure Transport exists.
The BRSKI-CLE document has a lot of text dealing with how the public keys are
derived. I don't really understand what the credential that is created by
the AC is... it looks like it's a signed object. I don't understand how it
would differ from all the work in OAUTH and ACE.
Second, I don't understand how to devices (having been enrolled) as depicted in
section 2.3, as client and server are able to trust each other. Maybe there
is some important magic that I've missed among the math.
I don't think that section 3 needs to educate us about Schnorr. I learnt
nothing about the trust algorithm from the math. Something about a Master
Key, which really scares me.
I would suggest that rather than tell us about the math, that the
presentation should explain to us the use case for this work.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
