You found a typo in the RFC, it should be CertificateVerify.signature.sha_hash as you noted. The reason it is not an HMAC, and the reason that no master secret seems to appear in the calculation, is because it is a public key signature. Using its private key, the client simply RSA encrypts the 36 bytes using PKCS#1 block type 1 padding (for an RSA certificate). _____________________________________ Greg Stark Ethentica, Inc. [EMAIL PROTECTED] _____________________________________ ----- Original Message ----- From: "ET Tan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, April 17, 2001 3:28 AM Subject: Re: Client Key Exchange > Thanks for your reply! > > I got another question, hope you can help me out. This is regarding > certificate verify message in TLS1. > > In section 7.4.8., it is mentioned that the certificate verify hashes are > to be generated as: > > CertificateVerify.signature.md5_hash > MD5(handshake_messages); > > Certificate.signature.sha_hash (shouldn't it be > CertificateVerify.?) > SHA(handshake_messages); > > Why is it that the MD5 and SHA1 are being used instead of the HMAC_MD5 and > HMAC_SHA?. > Also, where is the participation of the master secret in the above hashing > operations? > > Thanks again Eric! > > ET. > > > > > At 23:59 12-04-01 -0700, you wrote: > >ET Tan <[EMAIL PROTECTED]> writes: > > > Here's a question on rfc 2246: TLS1. > > > > > > According to this document, the Client Key Exchange message is exactly the > > > same as the one in SSL 3. However, I've observed that in TLS1, there are > > > additional 2 bytes describing the length of the RSA-encrypted pre-master. > > > > > > SSL3: > > > 16 03 00 RR RR 10 MM MM MM [Encrypted pre-master follows] > > > > > > TLS1: > > > 16 03 01 RR RR 10 MM MM MM XX XX [Encrypted pre-master follows] > > > > > > RR RR: Length of record > > > MM MM MM: Length of message > > > XX XX: Length of encrypted pre-master (????) > >Yes. > > > > > I am wondering why are the additional 2 bytes (XX XX) not mentioned in rfc > > > 2246. > >They are. Section 4.7 says that a "public-key-encrypted" element > >is encoded as an opaque <0..2^16-1>. > > > >The SSLv3 spec was unclear on this and since Netscape didn't > >use the length bytes, nobody else did either. The TLS spec is clear > >on this and so the TLS message is slightly different. > > > >-Ekr > > > > > >[Eric Rescorla [EMAIL PROTECTED]] > >Author of "SSL and TLS: Designing and Building Secure Systems" > > http://www.rtfm.com/ > > > > > >______________________________________________________________________ > >OpenSSL Project http://www.openssl.org > >User Support Mailing List [EMAIL PROTECTED] > >Automated List Manager [EMAIL PROTECTED] > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
