Hi Arnaud,
Arnaud Ebalard a écrit :
Hi,
Eric Levy-Abegnoli <[email protected]> writes:
Sheng,
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?
I agree clarification would be useful, given that several implementors
are asking for it. No question on that.
I disagree that there are several ways of interpreting it. Basically,
you have a well-formed icmp message, which include a valid checksum, and
you build a pseudo message by taking a number of fields out of it,
including the checksum, and then you sign it.Once you have added your
RSA option, another specification (icmp) mandate that you fix the
checksum to make it correct.
And it has been implemented by multiple vendors.
I checked the code and NTT Docomo SEND daemon does 'A' (i should have
checked before my first reply to Sheng):
It computes the checksum on current ICMPv6 message before the Signature
computation, uses that during the signature step and then recomputes the
checksum after the signature option has been added to the message.
So does the Juniper, Cisco (and a few others) implementations.
Otherwise, they would not inter-operate.
Eric
Moving to B would not be backward compatible and would create
inter-operability issues.
Clarifying the spec would help in all cases.
Cheers,
a+
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
