Hi Michael, Thank you for your comments. On 20. Jul 2023, Michael Richardson <[email protected]<mailto:[email protected]>> wrote:
>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 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. Yes, you are right. BRSKI-CLE just changes the enrollment phase in BRSKI. I think enrollment is also a part of the bootstrap process in BRSKI, as shown in RFC8995. Therefore, I think BRSKI-CLE somehow changes the process of BRSKI. I saw BRSKI-AE is a working group draft. Thus, I think BRSKI-CLE is also suitable under the auspices of the ANIMA WG. >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. >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. The AC is a trusted third party, similar to the CA. The CA uses its private key to sign the pledge's public key. Other pledges use the CA's public key to verify whether the signature is signed by the CA. The AC adds its public and private keys to the process of generating the pledge's public and private keys. Other pledges can also use the AC's public key to verify whether the credential, which can derive the pledge's public key, is generated by the AC. >I don't understand how it would differ from all the work in OAUTH and ACE. A token is used by a client to request resources from a server in the scenario of ACE-OAUTH [RFC9200]. In BRSKI-CLE, the usage of the credential is more general. The pledge's action after the authentication using credentials is not specified in BRSKI-CLE. >I don't think that section 3 needs to educate us about Schnorr. I learnt >nothing about the trust algorithm from the math. The certificateless cryptography in BRSKI-CLE is similar to ECDSA and ECDHE. I wrote these algorithms because I think it is necessary to explain the principle of certificateless authentication for applying it in BRSKI. Now, I also realize putting the math algorithms in this draft may not be suitable. However, I don't know which working group is proper for promoting the certificateless cryptography algorithms. Do you have any suggestions? >Something about a Master Key, which really scares me. The master key is a symmetric key, which can only be figured out by the two communicating peers, similar to the symmetric key generated by ECDHE. And the master key is used to derive the keys utilized in the communication later, similar to the master secret in TLS v1.3. >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 <[email protected]<mailto:[email protected]>> . o >O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide Best regards, Lei YAN
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
