Hi Steve, One more thing for you to think just in case you will continue with your effort of extending the digest framework for this:
>Is usage of the private key somehow embedded into your definition of >KD(data) or is signing applied to the hashed string that is received as >a result from KD(data) ? > >[SD] It appears the H(data) is unnecessary, KD could denote the hashing >and encrypting (signing) of the string of data. I believe that you have to separate the steps of (a) hashing and (b) encrypting the hash like suggested in my comment: >the process should instead go like this: > >1. The UA creates a hash of the SIP request and the nonce >2. The UA encrypts the resulting hash with its private key > and sends this digital signature along with the SIP request > >3. The server also creates a hash of the SIP request and the nonce >4. The server decrypts the encrypted string with the public > key and compares the result to the hash it created in step 3. Thus you probably need to define two functions: a) One for creating the hash from the SIP request. This function does not use any secret or public key. Most probably the parts of the request to be hashed are as specified in AIB RFC 3893. b) Another for creating the digital signature over the hash. This function takes as its input the hash from the previous step and the private key related to user's certificate. These two functions could use different hash functions, so you have to specify both. P.S. Please do not believe me to be an experienced security expert, I am just in process of learning cryptography by myself. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
