[Mono-bugs] [Bug 81511][Nor] Changed - TlsClientCertificate verifyCertificateUsage differs from spec

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by bugzilla at woy.nl.

http://bugzilla.ximian.com/show_bug.cgi?id=81511

--- shadow/81511	2007-05-02 08:34:50.000000000 -0400
+++ shadow/81511.tmp.14843	2007-05-02 11:05:23.000000000 -0400
@@ -45,6 +45,28 @@
 Note that OpenSSL and Mozilla != specs ;-) Every app/lib has it's own
 rules (worse if they existed before the RFC) and it's impossible to be
 compatible with 100% of them without removing all certificate checks :(
 
 Anyway I'll check the RFCs and make any required adjustments (if
 required). Thanks
+
+------- Additional Comments From bugzilla at woy.nl  2007-05-02 11:05 -------
+Yes I Know those are not the specs ;). But I couldn't find it clearly
+in the specs.
+
+As far as I know the Client private key is only used for the
+Certificate Verify message. This message is a signature over some date
+used in the handshake. So it seems logical that the certificate should
+support digitalSignature
+In rfc2246 7.4.8. Certificate verify
+
+As far as I can find the only key encryption the client does is in the
+ClientKeyExchange message. The specs say that the MasterSecret is
+encrypted with the public key of the ServerCertificate( rfc2246
+7.4.7.1 ). But I don't see why this should be a reason that the
+ClientCertificate should have permission for KeyEncryption.
+
+As far as I can find in the specs the only requirement for the
+KeyEnchiperment bit is in rfc2246 chapter 7.4.2. But that is regarding
+the server certificate.
+
+I hope this helps.