Re: -15 still not clear on signatures

[Ben Laurie <ben@xxxxxxxxxxxxx>]

David Shaw wrote:
> On Mon, Dec 05, 2005 at 06:03:17PM -0500, David Shaw wrote:
>> On Sat, Nov 26, 2005 at 02:04:11PM +0000, Ben Laurie wrote:
> 
>>> b) EMSA-PKCS1-v1_5 takes two parameters - the message, m, and the length
>>> of the encoded message, emLen. emLen is not specified in -15. By
>>> inspection of existing signatures, it seems to me it is one less than
>>> the size of the modulus (which strikes me as theoretically wrong, but if
>>> that's the way it is, I guess that's the way it is).
>> I was under the impression that emLen was equal to the size of the
>> modulus.  I'm a bit confused with the two different descriptions of
>> EMSA-PKCS1-v1_5 (one in rfc-2437, and one in rfc-3447).  The leading
>> zero seems to have been added outside of EMSA-PKCS1-v1_5 in 2437 and
>> within it in 3447.
> 
> I did some digging and I think I see the problem here.  2440 and 1991
> correctly describe the encoding.  The instructions in 2440bis will not
> work as EMSA-PKCS1-v1_5 (the RFC-2437 version) is only part of the
> correct encoding.  The encoding is effectively to calculate
> EMSA-PKCS1-v1_5-ENCODE (m, emLen - 1) and then prefix the resulting
> octet string with a zero octet.  There is a similar situation with
> leading zeroes for EME-PKCS1-v1_5 for the encrypted session key
> packets.
> 
> To make things more complicated, EMSA-PKCS1-v1_5-ENCODE and
> EME-PKCS1-v1_5-ENCODE in RFC-3447 *are* the correct encodings, leading
> zero and all.
> 
> Since 3447 obsoletes 2437 anyway, maybe the easiest fix is to use 3447
> and add a note along the lines of "Use 3447 and not 2437 - we really
> mean it".

Assuming you are right about 3447 (I haven't checked it), then definitely.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff