This issue is one that I was dealing with while driving grapes back from the vineyard yesterday. I don't know that it needs to have any changes in the draft. I am putting this out to see if there is any controversy on the decisions that I would make about this issue.
The client is going to use client authorization with the TLS tunnel. I make the assumption that the client does successfully authenticate the server's certificate and we are not in a total anonymous situation. At this point I believe the following possible scenarios exist: 1. The client provides no certificate - This would be accepted depending on the server policy about requiring a client certificate to be presented. 2. The client provides a certificate in the clear - This could be either a user or machine certificate, the server would check the identity against Its database (with the proviso that the certificate could be the entry in the database) and either accepts or rejects the TLS connection based on the identity presented. This would be done via a TLS alert. Note, I did have an argument with myself about the possibility that the server would accept the certificate and treat it as if it was an anonymous client. 3. The client provides the certificate in a protected manner - I had a problem at this point because I don't know enough TLS to properly go through this scenario, and I could not really read documents while driving. If the encrypted certificate extension was used, then there is no issue as the protected certificate would be passed in the initial handshake. However if the client starts the negotiation and then restarts it after it is encrypted, I don't know if this occurs before or after the finish message. If it starts after the finish method then there is an issue with having the server close an anonymous session if the client is then going to provide the certificate encrypted. Help on how this works would be appreciated. Jim _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
