Struct trust_dns_proto::rr::rdata::caa::CAA

source ·

pub struct CAA { /* private fields */ }

Expand description

The CAA RR Type

RFC 6844, DNS Certification Authority Authorization, January 2013

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 "http://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§

source §

impl CAA

source

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.

source

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.

source

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