[David Fort <david.fort@xxxxxxxx>]

Guy Harris wrote:

> Section 4.1.6 says
>
> 4.1.6 Key Tag Field
>
>    The "key Tag" is a two octet quantity that is used to efficiently
>    select between multiple keys which may be applicable and thus check
>    that a public key about to be used for the computationally expensive
>    effort to check the signature is possibly valid.  For algorithm 1
>    (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two
>    octets of the public key modulus needed to decode the signature
>    field.  That is to say, the most significant 16 of the least
>    significant 24 bits of the modulus in network (big endian) order. For
>    all other algorithms, including private algorithms, it is calculated
>    as a simple checksum of the KEY RR as described in Appendix C.
>
> So should "compute_key_id()" use the two octets in question for 
> DNS_ALGO_RSAMD5, rather than for DNS_ALGO_RSASHA1 as it does now?
compute_key_id DO use the two octets in question:
 switch( algo ) {
    case DNS_ALGO_RSAMD5:
      return (tvb_get_guint8(tvb, offset + size - 3) << 8) + 
tvb_get_guint8( tvb, offset + size - 2 );

The RFC says that the checksum should be used for anything else than 
RSA/MD5. RSA/SHA1 is clearly matching that
case. The patch i sent you changes the RSA/SHA1 behaviour to being the 
default one for all algorithm(which is what the RFC
specifies), so the compute_key_id always returns a valid key id.
Talking about that i was thinking of giving more informations about the 
key(nb of bits, modulus, etc..). But for achieving this i'd like
to use openSSL to decode the cryptographic material. Is openSSL detected 
and linked with ethereal ? If so which symbol is defined when openSSL
is present ?

--
Fort David, Projet IDsA
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
T�l: +33 (0) 2 99 84 71 33