[−][src]Struct trust_dns_client::rr::rdata::KEY
RFC 2535, Domain Name System Security Extensions, March 1999
3. The KEY Resource Record
The KEY resource record (RR) is used to store a public key that is
associated with a Domain Name System (DNS) name. This can be the
public key of a zone, a user, or a host or other end entity. Security
aware DNS implementations MUST be designed to handle at least two
simultaneously valid keys of the same type associated with the same
name.
The type number for the KEY RR is 25.
A KEY RR is, like any other RR, authenticated by a SIG RR. KEY RRs
must be signed by a zone level key.
3.1 KEY RDATA format
The RDATA for a KEY RR consists of flags, a protocol octet, the
algorithm number octet, and the public key itself. The format is as
follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | protocol | algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
The KEY RR is not intended for storage of certificates and a separate
certificate RR has been developed for that purpose, defined in [RFC
2538].
The meaning of the KEY RR owner name, flags, and protocol octet are
described in Sections 3.1.1 through 3.1.5 below. The flags and
algorithm must be examined before any data following the algorithm
octet as they control the existence and format of any following data.
The algorithm and public key fields are described in Section 3.2.
The format of the public key is algorithm dependent.
KEY RRs do not specify their validity period but their authenticating
SIG RR(s) do as described in Section 4 below.
3.1.1 Object Types, DNS Names, and Keys
The public key in a KEY RR is for the object named in the owner name.
A DNS name may refer to three different categories of things. For
example, foo.host.example could be (1) a zone, (2) a host or other
end entity , or (3) the mapping into a DNS name of the user or
account foo@host.example. Thus, there are flag bits, as described
below, in the KEY RR to indicate with which of these roles the owner
name and public key are associated. Note that an appropriate zone
KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs
occur only at delegation points.
3.1.2 The KEY RR Flag Field
In the "flags" field:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Bit 0 and 1 are the key "type" bits whose values have the following
meanings:
10: Use of the key is prohibited for authentication.
01: Use of the key is prohibited for confidentiality.
00: 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.
11: If both bits 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. See section 3.4 below.
Bits 2 is reserved and must be zero.
Bits 3 is reserved as a flag extension bit. If it is a one, a second
16 bit flag field is added after the algorithm octet and
before the key data. This bit MUST NOT be set unless one or
more such additional bits have been defined and are non-zero.
Bits 4-5 are reserved and must be zero.
Bits 6 and 7 form a field that encodes the name type. Field values
have the following meanings:
00: 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.example could have a public key associated
through a KEY RR with name
j_random_user.host.subdomain.example. It could be used
in a 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.
01: 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 the primary DNS security feature of data origin
authentication. Zone KEY RRs occur only at delegation
points.
10: 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] or numeric IP address. This is the
public key used in connection with DNS request and
transaction authentication services. It could also be
used in an IP-security protocol where authentication at
the host, rather than user, level was desired, such as
routing, NTP, etc.
11: reserved.
Bits 8-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 things as specified in DNS
dynamic update [RFC 2137]. Note that zone keys (see bits
6 and 7 above) always have authority to sign any RRs in
the zone regardless of the value of the signatory field.
Implementations
impl KEY
[src]
pub fn new(
key_trust: KeyTrust,
key_usage: KeyUsage,
signatory: UpdateScope,
protocol: Protocol,
algorithm: Algorithm,
public_key: Vec<u8>
) -> KEY
[src]
key_trust: KeyTrust,
key_usage: KeyUsage,
signatory: UpdateScope,
protocol: Protocol,
algorithm: Algorithm,
public_key: Vec<u8>
) -> KEY
Construct a new KEY RData
Arguments
key_trust
- declare the security level of this keykey_usage
- what type of thing is this key associated torevoke
- this key has been revokedalgorithm
- specifies the algorithm which this Key uses to sign recordspublic_key
- the public key material, in native endian, the emitter will perform any necessary conversion
Return
A new KEY RData for use in a Resource Record
pub fn key_trust(&self) -> KeyTrust
[src]
Returns the trust level of the key
pub fn key_usage(&self) -> KeyUsage
[src]
Returns the entity type using this key
pub fn signatory(&self) -> UpdateScope
[src]
Returns the signatory information of the KEY
pub fn revoke(&self) -> bool
[src]
Returns true if the key_trust is DoNotTrust
pub fn protocol(&self) -> Protocol
[src]
Returns the protocol which this key can be used with
pub fn algorithm(&self) -> Algorithm
[src]
RFC 4034, DNSSEC Resource Records, March 2005
2.1.3. The Algorithm Field
The Algorithm field identifies the public key's cryptographic
algorithm and determines the format of the Public Key field. A list
of DNSSEC algorithm types can be found in Appendix A.1
pub fn public_key(&self) -> &[u8]
[src]
RFC 4034, DNSSEC Resource Records, March 2005
2.1.4. The Public Key Field
The Public Key Field holds the public key material. The format
depends on the algorithm of the key being stored and is described in
separate documents.
Trait Implementations
impl Clone for KEY
[src]
impl Debug for KEY
[src]
impl Eq for KEY
[src]
impl From<KEY> for RData
[src]
impl Hash for KEY
[src]
pub fn hash<__H>(&self, state: &mut __H) where
__H: Hasher,
[src]
__H: Hasher,
fn hash_slice<H>(data: &[Self], state: &mut H) where
H: Hasher,
1.3.0[src]
H: Hasher,
impl PartialEq<KEY> for KEY
[src]
impl StructuralEq for KEY
[src]
impl StructuralPartialEq for KEY
[src]
impl Verifier for KEY
[src]
pub fn algorithm(&self) -> Algorithm
[src]
pub fn key(&'k self) -> Result<PublicKeyEnum<'k>, ProtoError>
[src]
fn verify(&self, hash: &[u8], signature: &[u8]) -> Result<(), ProtoError>
[src]
fn verify_message<M>(
&self,
message: &M,
signature: &[u8],
sig0: &SIG
) -> Result<(), ProtoError> where
M: BinEncodable,
[src]
&self,
message: &M,
signature: &[u8],
sig0: &SIG
) -> Result<(), ProtoError> where
M: BinEncodable,
fn verify_rrsig(
&self,
name: &Name,
dns_class: DNSClass,
sig: &SIG,
records: &[Record]
) -> Result<(), ProtoError>
[src]
&self,
name: &Name,
dns_class: DNSClass,
sig: &SIG,
records: &[Record]
) -> Result<(), ProtoError>
Auto Trait Implementations
impl RefUnwindSafe for KEY
impl Send for KEY
impl Sync for KEY
impl Unpin for KEY
impl UnwindSafe for KEY
Blanket Implementations
impl<T> Any for T where
T: 'static + ?Sized,
[src]
T: 'static + ?Sized,
impl<T> Borrow<T> for T where
T: ?Sized,
[src]
T: ?Sized,
impl<T> BorrowMut<T> for T where
T: ?Sized,
[src]
T: ?Sized,
pub fn borrow_mut(&mut self) -> &mut T
[src]
impl<T> From<T> for T
[src]
impl<T, U> Into<U> for T where
U: From<T>,
[src]
U: From<T>,
impl<T> ToOwned for T where
T: Clone,
[src]
T: Clone,
type Owned = T
The resulting type after obtaining ownership.
pub fn to_owned(&self) -> T
[src]
pub fn clone_into(&self, target: &mut T)
[src]
impl<T, U> TryFrom<U> for T where
U: Into<T>,
[src]
U: Into<T>,
type Error = Infallible
The type returned in the event of a conversion error.
pub fn try_from(value: U) -> Result<T, <T as TryFrom<U>>::Error>
[src]
impl<T, U> TryInto<U> for T where
U: TryFrom<T>,
[src]
U: TryFrom<T>,
type Error = <U as TryFrom<T>>::Error
The type returned in the event of a conversion error.
pub fn try_into(self) -> Result<U, <U as TryFrom<T>>::Error>
[src]
impl<V, T> VZip<V> for T where
V: MultiLane<T>,
V: MultiLane<T>,