Re: [CGA-EXT] Review of draft-ietf-csi-proxy-send

[Tony Cheneau <[e-mail]>]

Hello Jari,

I'm not author of this document, but I implemented a bit of the SEND
protocol, so I think I can answer this one:

>>        This field starts after the Key Hash field.  The length of the
>>        Digital Signature field is determined by the length of the RSA
>>        Signature option minus the length of the other fields (including
>>        the variable length Pad field.)
>>
>>     Padding
>>
>>        This variable-length field contains padding, as many bytes long as
>>        remain after the end of the signature.
>> 
>
> I don't understand how to calculate the length of the Signature field, 
> because the padding field's length is not described anywhere.

The padding field is exactly defined this way in RFC 3971 (although a
Pad Length field was present on the -04 version of the SEND draft). 
I think the draft-ietf-csi-proxy-send-01 document only reuses the format
of the badly defined RSA Signature Option.

In the RSA signature option, you can check with the Key Hash field which
Public Key is linked to the Digital Signature field (it is often carried
by the CGA Option).  Then, the Public Key length determines the size of
the Digital Signature (1024 bits long key = 128 octets long Digital
Signature). Hence, you have a way to determine the size of the padding.

If you use a different Signature Algorithm with a varying Digital
Signature size, you still can choose to encode it in a DER-like format
(but this is mostly an hack...).

If RFC 3971 was to be updated, I agree that a padding length field should 
be defined somewhere in the RSA (or XXX) Signature Option. 
Was there a rational behind its removal during the RFC 3971
standardisation process ?

Regards,
 	Tony