Bit 0 and 1 are the key "type" field. Bit 0 a one indicates
that use of the key is prohibited for authentication. Bit 1 a one
indicates that use of the key is prohibited for confidentiality. If
this field is zero, then use of the key for authentication and/or
confidentiality is permitted. Note that DNS security makes use of
keys for authentication only. Confidentiality use flagging is
provided for use of keys in other protocols. Implementations not
intended to support key distribution for confidentiality MAY require
that the confidentiality use prohibited bit be on for keys they
serve. If both bits of this field are one, the "no key" value, there
is no key information and the RR stops after the algorithm octet. By
the use of this "no key" value, a signed KEY RR can authenticatably
assert that, for example, a zone is not secured.
Bit 2 is the "experimental" bit. It is ignored if the type
field indicates "no key" and the following description assumes that
type field to be non-zero. Keys may be associated with zones,
entities, or users for experimental, trial, or optional use, in which
case this bit will be one. If this bit is a zero, it means that the
use or availability of security based on the key is "mandatory".
Thus, if this bit is off for a zone key, the zone should be assumed
secured by SIG RRs and any responses indicating the zone is not
secured should be considered bogus. If this bit is a one for a host
or end entity, it might sometimes operate in a secure mode and at
other times operate without security. The experimental bit, like all
other aspects of the KEY RR, is only effective if the KEY RR is
appropriately signed by a SIG RR. The experimental bit must be zero
for safe secure operation and should only be a one for a minimal
transition period.
Bits 3-4 are reserved and must be zero.
Bit 5 on indicates that this is a key associated with a "user"
or "account" at an end entity, usually a host. The coding of the
owner name is that used for the responsible individual mailbox in the
SOA and RP RRs: The owner name is the user name as the name of a node
under the entity name. For example, "j.random_user" on
host.subdomain.domain could have a public key associated through a
KEY RR with name j\.random_user.host.subdomain.domain and the user
bit a one. It could be used in an security protocol where
authentication of a user was desired. This key might be useful in IP
or other security for a user level service such a telnet, ftp,
rlogin, etc.
Bit 6 on indicates that this is a key associated with the non-
zone "entity" whose name is the RR owner name. This will commonly be
a host but could, in some parts of the DNS tree, be some other type
of entity such as a telephone number [RFC 1530]. This is the public
key used in connection with the optional DNS transaction
authentication service if the owner name is a DNS server host. It
could also be used in an IP-security protocol where authentication of
at the host, rather than user, level was desired, such as routing,
NTP, etc.
Bit 7 is the "zone" bit and indicates that this is a zone key
for the zone whose name is the KEY RR owner name. This is the public
key used for DNS data origin authentication.
Bit 8 is reserved to be the IPSEC [RFC 1825] bit and indicates
that this key is valid for use in conjunction with that security
standard. This key could be used in connection with secured
communication on behalf of an end entity or user whose name is the
owner name of the KEY RR if the entity or user bits are on. The
presence of a KEY resource with the IPSEC and entity bits on and
experimental and no-key bits off is an assertion that the host speaks
IPSEC.
Bit 9 is reserved to be the "email" bit and indicate that this
key is valid for use in conjunction with MIME security multiparts.
This key could be used in connection with secured communication on
behalf of an end entity or user whose name is the owner name of the
KEY RR if the entity or user bits are on.
Bits 10-11 are reserved and must be zero.
Bits 12-15 are the "signatory" field. If non-zero, they
indicate that the key can validly sign RRs or updates of the same
name. If the owner name is a wildcard, then RRs or updates with any
name which is in the wildcard's scope can be signed. Fifteen
different non-zero values are possible for this field and any
differences in their meaning are reserved for definition in
connection with DNS dynamic update or other new DNS commands. Zone
keys always have authority to sign any RRs in the zone regardless of
the value of this field. The signatory field, like all other aspects
of the KEY RR, is only effective if the KEY RR is appropriately
signed by a SIG RR.
