[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IPSECKEY] IPSECKEY inheritance of DNSSEC algorithm registry



Sam Weiler wrote:

> The chairs would particularly like feedback on whether or not the
> IPSECKEY record should inherit format definitions from the DNS
> Security Algorithm registry -- if someone defines a (DNS)KEY RR format
> for Sam's Public Key Algorithm, does it automagically show up as an
> IPSECKEY format?

I am in favour of inheriting the definitions.  The same definitions
are currently being reused in HIP, and I am proposing that we use
those also in SEND.  (SEND currently specifies ASN.1 OIDs, but I
personally see little value in that.)

In particular, what comes to the following:

> 2.3 RDATA format - algorithm type
> 
....
>    The public key field contains the algorithm-specific portion of the
>    KEY RR RDATA, omitting the first four octets of the KEY RR RDATA.
>    This is the same portion of the KEY RR that must be specified by
>    documents that define a DNSSEC algorithm.  Those documents also
>    specify a message digest to be used for generation of SIG RRs; that
>    specification is not relevant to the IPSECKEY usage of the public key
>    format.

I think the intention of the text is excellent.  It aligns very
well with the current HIP usage of RFC2535 key formats.  However,
it might be good to explicitly mention that the first four octets
would contain the flags, protocol, and algorithm fields, which
are now left away.

A couple of comments:

   Should there be a reserved octed before the gateway field,
   thereby aligning the gateway field to 32-bit boundary?

   AAAA RDATA format is defined in Section 2.2 (not 3.2) of RFC1886.

--Pekka Nikander

-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.