Eliot gave me some hint offline and here's what we can do in TEAP with regards of certificate provisioning/enrollment/renewal.
In the current TEAP RFC, when the peer wants to get list of Trusted Roots it sends Trusted-Server-Root TLV with credential type field - a constant value 1 for PKCS#7 and with no other content. The server replies with Trusted-Server-Root TLV and puts PKCS#7 inside it. So there's a kind of request-response with the same TLV. However for certificate request the peer should send PKCS#10 TLV and the server should response with PKCS#7 TLV. It shows some inconsistency on one hand and gives no possibility for the server to control certificate renewal.. Suggest closing that gap by introducing a new "Peer-Certificate TLV" with exactly the same format as Trusted-Server-Root TLV. - When the peer wants to request a certificate it sends "Peer-Certificate TLV" with credential type field equal to 1 for PKCS#7 and optional PKCS#10 TLV as a content - If no PKCS#10 TLV attached then the server can just renew the existing certificate if it has such capabilities and required data (or can say that the peer wants a certificate based on its current certificate and the current server policies). - If PKCS#10 TLV is attached then the server generates peer certificate according to the data in the request - If the server wants to generate peer certificate it may reply with "Peer-Certificate TLV" with credential type field equal to 1 for PKCS#7 and PKCS#10 TLV as a content. - If the server wants the peer to send certificate request with all the data - it sends "Peer-Certificate TLV" with credential type field equal to 1 for PKCS#7 and no content - We don't need to use Request-Action TLV in the whole flow Would that work? Regards Oleg On Wed, May 6, 2020 at 4:57 PM Oleg Pekar <oleg.pekar.2...@gmail.com> wrote: > 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
