Hi Eliot, Few thoughts: - If the current client's certificate was requested via TEAP by PKCS#10 TLV - then maybe it makes sense for the client to send Request-Action TLV + PKCS#10 TLV again with the same certificate parameters - If the current client's certificate was not requested via TEAP - then there's no evidence that the certificate renewal will be addressed (maybe TEAP is not connected to any CA) - If the current client's certificate was obtained from the external CA (e.g. via SCEP or EST) - then there's no evidence that the certificate renewal will be addressed - If the current client's certificate was preinstalled - then the client may not have a clue what does it want and will be unable to fill PKCS#10 request. On the other hand, the CA that TEAP server is connected to could be unable to generate certificate with exactly the same properties and the current client certificate. Simple example: the current certificate is ECDSA and the CA can generate RSA only. Hard example: the current client certificate contains vendor specific extensions like Policy or Template Name. So it will be hard to put those extensions to the generated certificate
Regards Oleg On Thu, Apr 30, 2020 at 4:19 PM Eliot Lear <lear=40cisco....@dmarc.ietf.org> wrote: > All: > > Here is a circumstance one could easily imagine, and in fact we attempted > to address in draft-lear-eap-teap-brski: > > Client requires a new certificate for some reason or another. Perhaps its > is about to expire, or perhaps the signer has been compromised, or what > have you. > > > We were thinking that we could use the Request-Action Frame for this > purpose with a type of PKCS#10. But that now seems wrong, as the language > in the draft states that one appends a Request-Action frame with a full > TLV, and not just a *type, * and further that the other end process the > TLV. In looking at Jouni’s code, he is doing precisely that with the PAC > TLV. > > And so it seems we have three choices: > > > - Create a new TLV that has a length of *two* that can be used in a > REQUEST_ACTION frame. > - Create a new TLV that is what we thought we meant: here is a list of > two(ish)-byte types whose TLVs I want you to send to me. > - Hard code the ordering of requests so everyone knows what to expect. > > > Each of these has its own problems. > > The first requires that we create a new EAP TYPE for TLV one end needs the > other to send, but it’s pretty easy to process. The second requires extra > processing but requires less standardization. The last seems to go against > the EAP model and reduces deployment flexibility. > > Thoughts? > > Eliot > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
