Re: [Hipsec] Re: The exact method used to generate a HIT from a HI

On Tue, Mar 18, 2003 at 02:50:42PM -0800, Pekka Nikander wrote:
> On Fri, Mar 14, 2003 at 02:27:26PM +0200, Pekka Nikander wrote:

Well I've never looked at real RDATA key records, or even code to deal with them, but my parsing of RFC2536 does not agree with yours :-)

So confusion - do we have an oracle in the room?

Quoting:

   DSA public keys are stored in the DNS as KEY RRs using algorithm    number 3 [RFC 2535]. The structure of the algorithm specific portion    of the RDATA part of this RR is as shown below. These fields, from Q    through Y are the "public key" part of the DSA KEY RR.

I take the last two sentances as being contradictory given the below structure:

           Field     Size
           -----     ----
            T         1  octet
            Q        20  octets
            P        64 + T*8  octets
            G        64 + T*8  octets
            Y        64 + T*8  octets

This is further confused by the later part from the SIG RR section:

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

   T is copied from the public key. It is not logically necessary in    the SIG but is present so that values of T > 8 can more conveniently    be used as an escape for extended versions of DSA or other algorithms    as later specified.

Which to me seems to suggest that T should actually be storred as part of the public key.

Unless of course the draft is confusing public key and "public key", with the former being the logical structure, and the latter being the physical structure storred in the KEY RR.

> > Unless of course, we're saying assume a fixed value for t?

Hmm - well I guess the real question would be if there is any advantage/disadvantage in including/not including T in the data to be hashed. If RFC2536 should be read as including T in the 'blob' of the 'public key', then obviously include it. If not then we have to decide if including T in the hash gains us anything?

> The remaining question seems to be what exactly to

Well my view is to use the draft-jokela-hip-packets-01.txt layout for the HOST_ID and HOST_ID_FQDN packets whereby we have our own explicit algorithm and host id fields. Then we just need to define the value of algorithm, and the contents of the host id.

For the latter I'd say whatever RFC2536 should be read as requiring

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

I'd actualy argue for assigning our own set of values for algorithm just so if we want to use a form that DNS records don't want to use we're not blocked. Or even we don't have to battle with the DNS extensions WG over the values and/or use of that field.

> My personal opinion would be to use the RFC2536 DSA format

Agreeed.

any other takers?

DF