Guy Harris wrote:
On Jan 14, 2004, at 9:42 AM, David Fort wrote:
This patch fixes things in the computation of key id, DNSsec RFC tells
that there's only two way of calculating key id: the RSAMD5 way and
the default one.
Which RFC is that? RFC 2535 says
3.2 The KEY Algorithm Number Specification
This octet is the key algorithm parallel to the same field for the
SIG resource as described in Section 4.1. The following values are
assigned:
VALUE Algorithm
0 - reserved, see Section 11
1 RSA/MD5 [RFC 2537] - recommended
2 Diffie-Hellman [RFC 2539] - optional, key only
3 DSA [RFC 2536] - MANDATORY
4 reserved for elliptic curve crypto
5-251 - available, see Section 11
252 reserved for indirect keys
253 private - domain name (see below)
254 private - OID (see below)
255 - reserved, see Section 11
Algorithm specific formats and procedures are given in separate
documents. The mandatory to implement for interoperability algorithm
is number 3, DSA. It is recommended that the RSA/MD5 algorithm,
number 1, also be implemented. Algorithm 2 is used to indicate
Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve.
Algorithm number 252 indicates an indirect key format where the
actual key material is elsewhere. This format is to be defined in a
separate document.
Algorithm numbers 253 and 254 are reserved for private use and will
never be assigned a specific algorithm. For number 253, the public
key area and the signature begin with a wire encoded domain name.
Only local domain name compression is permitted. The domain name
indicates the private algorithm to use and the remainder of the
public key area is whatever is required by that algorithm. For
number 254, the public key area for the KEY RR and the signature
begin with an unsigned length byte followed by a BER encoded Object
Identifier (ISO OID) of that length. The OID indicates the private
algorithm in use and the remainder of the area is whatever is
required by that algorithm. Entities should only use domain names
and OIDs they control to designate their private algorithms.
Values 0 and 255 are reserved but the value 0 is used in the
algorithm field when that field is not used. An example is in a KEY
RR with the top two flag bits on, the "no-key" value, where no key is
present.
Appendix C: Key Tag Calculation
The key tag field in the SIG RR is just a means of more efficiently
selecting the correct KEY RR to use when there is more than one KEY
RR candidate available, for example, in verifying a signature. It is
possible for more than one candidate key to have the same tag, in
which case each must be tried until one works or all fail. The
following reference implementation of how to calculate the Key Tag,
for all algorithms other than algorithm 1, is in ANSI C. It is coded
for clarity, not efficiency. (See section 4.1.6 for how to determine
the Key Tag of an algorithm 1 key.)
[...]
The RFC is not very well organized on that point, i don't see why this is
done in appendix when it should be in the key or sig description.
--
Fort David, Projet IDsA
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tél: +33 (0) 2 99 84 71 33
