1 - 2 - 8 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W - Z
Entity
Click on the red underlined text to get to the source
... public key
parameters, and a variety of flags including those indicating the
type of entity the key is associated with and/or asserting that there
is no key associated with that entity.
...
... type of entity the key is associated with and/or asserting that there
is no key associated with that entity.
...
... private key. One is for support of dynamic update
where an entity is permitted to authenticate/update its own records.
...
... update its own records.
The public key of the entity must be present in the DNS and be
appropriately signed but the other RR ...
... appropriately signed but the other RR(s) may be signed with the
entity's key. The other is for support of transaction and request
authentication ...
... things. For example, dee.cybercash.com could be (1) a zone, (2) a
host or other end entity , and (3) the mapping into a DNS name of the
user or account dee@cybercash.com. Thus, there are flags, as
...
... 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 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 ...
... user name as the name of a node
under the entity name. For example, "j.random_user" on
host.subdomain.domain ...
... 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 ...
... host but could, in some parts of the DNS tree, be some other type
of entity such as a telephone number [RFC1530]. This is the public
key ...
... 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 ...
... 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 ...
... bits are on. The
presence of a KEY resource with the IPSEC and entity bits on and
experimental ...
... 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 ...
... end entity or user whose name is the owner name of the
KEY RR if the entity or user bits are on.
...
... protocol octet is provided to indicate
that a key is valid for such use and, for end entity keys or the host
part of user keys, that the secure version ...
... part of user keys, that the secure version of that protocol is
implemented on that entity or host.
...
... allocated, a key can be simultaneously indicated as valid for that
protocol and the entity or host can be simultaneously flagged as
implementing the secure version ...
... On retrieval of type A or AAAA RRs, the end entity KEY RR(s) MUST
be included if space is available. On inclusion of A or AAAA ...
... RRs authenticated
by SIGs signed by entity keys or the like MUST still be validated.
The AXFR ...
... wildcard of the KEY type with the no-key type value
and with no type (zone, entity, or user) bit on. This will cause
there to be one zone covering NXT RR ...
... off-line and carefully guarded is 13 months with the intent that
they be replaced every year. A reasonable maximum lifetime for end
entity and useer keys that are used for IP-security or the like and
...
... security or the like and
are kept on line is 36 days with the intent that they be replaced
monthly or more often. In some cases, an entity key lifetime of
somewhat over a day may be reasonable.
...