Hi,
Eric Levy-Abegnoli <[email protected]> writes:
>>> Currently, I see onle one possibility, which is A. It is
>>> un-ambiguously specified in rfc3971.
>>>
>>
>> I respectfully disagree (not on the definitive solution). My previous
>> post in March 2008 and the one from Sheng just prove this is not
>> "un-ambiguously" specified.
>>
>>
> complicated, or not detailed enough does not mean it is ambiguous. I read:
>
> Digital Signature
> A variable-length field containing a PKCS#1 v1.5 signature,
> constructed by using the sender's private key over the following
> sequence of octets:
>
> [snip]
>
> 4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the
> ICMP header.
>
> ...
> It does not say "0", it says checksum from the icmp header. How could
> "0" be the checksum of the icmp header?
Just for the discussion: Usually, the checksuming is done at the end of
option inclusion. Meanwhile (at least in most C implementations, i
guess, the checksum field is null in the structure due to an initial
memset(,0,)). But I guess one can say that "The message is constructed
in its entirety, without the RSA Signature option" must be understood as
"The message is constructed in its entirety, with the checksum field set
but without the RSA Signature"
IMHO, Changing the list in 5.2.1 to:
A node sending a message with the RSA Signature option MUST construct
the message as follows:
o The message is constructed in its entirety, without the RSA
Signature option. This includes usual checksum computation over
current layout.
o The RSA Signature option is added as the last option in the
message.
o The data to be signed is constructed as explained in Section 5.2,
under the description of the Digital Signature field.
o The message, in the form defined above, is signed by using the
configured private key, and the resulting PKCS#1 v1.5 signature is
put in the Digital Signature field.
o As described in [RFC2463], ICMPv6 checksum field is updated to
reflect the addition of the RSA Signature Option.
make things clear.
> I agree clarification would be useful, given that several implementors
> are asking for it. No question on that.
yes.
BTW, while I am at it, was I the only one to read the description of the
Timestamp field multiple times (in 5.3.1. "Timestamp Option") to be sure
my code would work for various arch (endianness)?
Cheers,
a+
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
