Struct hickory_proto::rr::rdata::caa::CAA

pub struct CAA { /* private fields */ }

The CAA RR Type

RFC 8659, DNS Certification Authority Authorization, November 2019

3.  The CAA RR Type

A CAA RR consists of a flags byte and a tag-value pair referred to as
a property.  Multiple properties MAY be associated with the same
domain name by publishing multiple CAA RRs at that domain name.  The
following flag is defined:

Issuer Critical:  If set to '1', indicates that the corresponding
   property tag MUST be understood if the semantics of the CAA record
   are to be correctly interpreted by an issuer.

   Issuers MUST NOT issue certificates for a domain if the relevant
   CAA Resource Record set contains unknown property tags that have
   the Critical bit set.

The following property tags are defined:

issue <Issuer Domain Name> [; <name>=<value> ]* :  The issue property
   entry authorizes the holder of the domain name <Issuer Domain
   Name> or a party acting under the explicit authority of the holder
   of that domain name to issue certificates for the domain in which
   the property is published.

issuewild <Issuer Domain Name> [; <name>=<value> ]* :  The issuewild
   property entry authorizes the holder of the domain name <Issuer
   Domain Name> or a party acting under the explicit authority of the
   holder of that domain name to issue wildcard certificates for the
   domain in which the property is published.

iodef <URL> :  Specifies a URL to which an issuer MAY report
   certificate issue requests that are inconsistent with the issuer's
   Certification Practices or Certificate Policy, or that a
   Certificate Evaluator may use to report observation of a possible
   policy violation.  The Incident Object Description Exchange Format
   (IODEF) format is used [RFC5070].

The following example is a DNS zone file (see [RFC1035]) that informs
CAs that certificates are not to be issued except by the holder of
the domain name 'ca.example.net' or an authorized agent thereof.
This policy applies to all subordinate domains under example.com.

$ORIGIN example.com
.       CAA 0 issue "ca.example.net"

If the domain name holder specifies one or more iodef properties, a
certificate issuer MAY report invalid certificate requests to that
address.  In the following example, the domain name holder specifies
that reports may be made by means of email with the IODEF data as an
attachment, a Web service [RFC6546], or both:

$ORIGIN example.com
.       CAA 0 issue "ca.example.net"
.       CAA 0 iodef "mailto:security@example.com"
.       CAA 0 iodef "https://iodef.example.com/"

A certificate issuer MAY specify additional parameters that allow
customers to specify additional parameters governing certificate
issuance.  This might be the Certificate Policy under which the
certificate is to be issued, the authentication process to be used
might be specified, or an account number specified by the CA to
enable these parameters to be retrieved.

For example, the CA 'ca.example.net' has requested its customer
'example.com' to specify the CA's account number '230123' in each of
the customer's CAA records.

$ORIGIN example.com
.       CAA 0 issue "ca.example.net; account=230123"

The syntax of additional parameters is a sequence of name-value pairs
as defined in Section 5.2.  The semantics of such parameters is left
to site policy and is outside the scope of this document.

The critical flag is intended to permit future versions CAA to
introduce new semantics that MUST be understood for correct
processing of the record, preventing conforming CAs that do not
recognize the new semantics from issuing certificates for the
indicated domains.

In the following example, the property 'tbs' is flagged as critical.
Neither the example.net CA nor any other issuer is authorized to
issue under either policy unless the processing rules for the 'tbs'
property tag are understood.

$ORIGIN example.com
.       CAA 0 issue "ca.example.net; policy=ev"
.       CAA 128 tbs "Unknown"

Note that the above restrictions only apply at certificate issue.
Since the validity of an end entity certificate is typically a year
or more, it is quite possible that the CAA records published at a
domain will change between the time a certificate was issued and
validation by a relying party.

Implementations

impl CAA

pub fn new_issue( issuer_critical: bool, name: Option<Name>, options: Vec<KeyValue> ) -> Self

Creates a new CAA issue record data, the tag is issue

Arguments

• issuer_critical - indicates that the corresponding property tag MUST be understood if the semantics of the CAA record are to be correctly interpreted by an issuer
• name - authorized to issue certificates for the associated record label
• options - additional options for the issuer, e.g. ‘account’, etc.

pub fn new_issuewild( issuer_critical: bool, name: Option<Name>, options: Vec<KeyValue> ) -> Self

Creates a new CAA issue record data, the tag is issuewild

Arguments

• issuer_critical - indicates that the corresponding property tag MUST be understood if the semantics of the CAA record are to be correctly interpreted by an issuer
• name - authorized to issue certificates for the associated record label
• options - additional options for the issuer, e.g. ‘account’, etc.

pub fn new_iodef(issuer_critical: bool, url: Url) -> Self

Creates a new CAA issue record data, the tag is iodef

Arguments

• issuer_critical - indicates that the corresponding property tag MUST be understood if the semantics of the CAA record are to be correctly interpreted by an issuer
• url - Url where issuer errors should be reported

Panics

If value is not Value::Issuer

pub fn issuer_critical(&self) -> bool

Indicates that the corresponding property tag MUST be understood if the semantics of the CAA record are to be correctly interpreted by an issuer

pub fn tag(&self) -> &Property

The property tag, see struct documentation

pub fn value(&self) -> &Value

a potentially associated value with the property tag, see struct documentation

Trait Implementations

impl BinEncodable for CAA

fn emit(&self, encoder: &mut BinEncoder<'_>) -> ProtoResult<()>

Write the type to the stream

fn to_bytes(&self) -> ProtoResult<Vec<u8>>

Returns the object in binary form

impl Clone for CAA

fn clone(&self) -> CAA

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for CAA

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for CAA

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Display for CAA

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl Hash for CAA

fn hash<__H: Hasher>(&self, state: &mut __H)

Feeds this value into the given Hasher.

fn hash_slice<H>(data: &[Self], state: &mut H)

where H: Hasher, Self: Sized,

Feeds a slice of this type into the given Hasher.

impl PartialEq for CAA

fn eq(&self, other: &CAA) -> bool

This method tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

This method tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl RecordData for CAA

fn try_from_rdata(data: RData) -> Result<Self, RData>

Attempts to convert to this RecordData from the RData type, if it is not the correct type the original is returned

fn try_borrow(data: &RData) -> Option<&Self>

Attempts to borrow this RecordData from the RData type, if it is not the correct type the original is returned

fn record_type(&self) -> RecordType

Get the associated RecordType for the RecordData

fn into_rdata(self) -> RData

Converts this RecordData into generic RecordData

impl Serialize for CAA

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl Eq for CAA

impl StructuralPartialEq for CAA