Hi all, I have a fundamental question about draft-lear-eap-teap-brski-05.
The draft makes an assumption about how a TLS client performs authentication of the server side. Because the client is unable to validate the server certificate it delays the authentication till it receives the voucher. The voucher is a fancy name for a certificate chain that allows the client to trace the chain back from the provided certificate to the manufacturer-provided certificate. Here is the relevant text: " o Step 2: Device establishes provisional TLS connection to registrar. The device establishes an outer TEAP tunnel with the TEAP server and does not validate the server certificate. " Which part of the text in the TLS spec makes you believe that this is actually supported via the spec (rather than being supported by some implementations*)? Additionally, the TLS stack needs to expose the server certificate via an API so that the application layer can perform this delayed authentication. Since the spec does not define an API, are you essentially relying on implementation-specific features here? Ciao Hannes (*): Mbed TLS supports this functionality but there may be other implementations that do not support this feature. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
