Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt

[Roy Arends <Roy.Arends@nominum.com>]

On Fri, 29 Jun 2001, Roy Arends wrote:

> 2) To indicate opt-in, a bit is set in the flag-field of the zone KEY.
> When I decide to sign the zone with an "opt-in" zone KEY and I sign the
> zone with a vanilla zone KEY (I can sign the zone with more than 1 KEY),
> there is no way of indicating how to create NXT RR. Would there be two NXT
> RR, one for opt-in view, one for rfc2535-style ? This is in my opinion
> very difficult to realise and probably breaks the scheme. Temporarily
> signing with both keys might be necessary when I'm moving from a
> rfc2535-style to opt-in-style or vice versa.

The following scheme proposes a slightly different solution that does not
require an allocation of a key's flag field bit, but uses bit zero of the
NXT's type bit map to indicate wether the zone is signed in rfc2535-style
or opt-in style. 

This solution allows a zone to have all 3 views, ie unsecure, rfc-2535
secured and opt-in secured. To the reader it might seem ambigu to have
both styles of secured styles in a zone, though this is required during a
key-rollover when an administrator decides to switch views. (it is not
explicitly forbidden to have a NXT RRset with more then 1 NXT RR). 

In my opinion, it should be the NXT record itself rather than the KEY
record to indicate how it should be interpreted.

About the zero bit:

rfc2535, section 5.2 mentions the zero bit.

	The first bit represents RR type zero (an illegal type which
	can not be present) and so will be zero in this format.  This format
	is not used if there exists an RR with a type number greater than
	127.  If the zero bit of the type bit map is a one, it indicates that
	a different format is being used which will always be the case if a
	type number greater than 127 is present.

As stated, if the type bit zero is a one, it indicates a different format.
The different format in this case is the opt-in format.

The null bit should be indicated with a value that is distinct from the RR
types.

The following example shows the rfc2535-style NXT: (zone: example.com.)

  alpha.example.com. NXT gamma.example.com. NS NXT DS

It indicates that there exists nothing between alpha & gamma. The existing
types for alpha are NS, NXT and DS. 

The following example shows the opt-in-style NXT: (zone: example.com.)

  alpha.example.com. NXT sigma.example.com. OO NXT DS

It indicates that there exists nothing that was signed between alpha &
sigma. The signed types for alpha are NXT and DS. Note that NS is never
signed as delegation. The opt-in is indicated with OO. This flag always
apears first as it is the null bit.  

Regards,

Roy Arends
Nominum