[lamps] CAA tags

[Tim Hollebeek <[e-mail]>]

Here is my tags proposal, in case others want to comment on it on this list.

 

Note that it has been privately pointed out to me that one possible solution
to the criticality problem and the scaling problem is to use top-level tags
that are independent of the issue records:

 

Something like:

 

CAA 0 issue "a.example.com"

CAA 0 issue "b.example.com"

CAA 128 validation "Phone"

 

-Tim

 

----------------------------------------------------------------------------
---------------------------------------------------------------------------


Introduction and Motivation


 

In addition to being able to specify which CA or CAs are allowed to issue
certificates for a given domain, RFC 6844 allows additional parameters, such
as the account number, that the CA can consume for a variety of uses.  RFC
6844 defines the format, but otherwise leaves the kinds of properties and
their meanings up to the issuer.

While this is appropriate for a technical standard, standardizing the names
and meanings of CAA properties across the CA industry has the following
benefits:

1.	Reduce user confusion when the same or similar property is used by
different CAs with different names and semantics
2.	Make it simpler to migrate from one CA to another while preserving
the CAA configuration
3.	Simplifying configuration and expression of CAA policies that allow
issuance from multiple CAs
4.	Allow CAA record creation tools to support creating CAA records that
contain properties that have been standardized


History


 

CAA property tags have been discussed at several CA/B Forum meetings, most
recently at the October meeting in Taipei.  Four were suggested: Acceptable
validation methods, an account identifier, certificate types (DV/OV/EV), and
ability to specify a brand.

 


Method of Adoption


 

Since these CAA properties are just a voluntary industry standard that any
CA could implement, they don't necessarily have to exist in a standards
document.  However, it seems like it would be helpful if the names and
semantics were agreed upon by the industry as a whole, so it is probably
best to include them in the Baseline Requirements as an optional feature CAs
MAY implement.

On the other hand, it might be desirable to reserve the names, and require
that if these particular property names are used, the semantics MUST be the
semantics specified in the Baseline Requirements.

 


Brands


 

I'm starting with this one because I'm going to argue it isn't necessary.
CAs can and do have multiple names that they accept in CAA records.  It is
hard to imagine a brand existing without the associated domain and website
also existing.  I'd suggest that CAs that maintain multiple brands simply
use a different domain name for each brand, e.g.

certs.example.com               CAA 0 issue "megaca.com"

catlover.example.com         CAA 0 issue "certsforcats.com"    #
certsforcats is a brand owned by MegaCA.

CAAs can also publicize examples of CAA records that allow for issuance by
all of their brands.


Acceptable Validation Methods


 

A list of acceptable validation methods can be specified using the
"validation" tag.

There are two challenges here, that have been discussed elsewhere in
relation to keeping records of which validation method was used for a
particular certificate.  The first is that validation methods can change
over time.  This seems to be less of a concern for issuance than it is for
historical validations, as a CAA record can and should be interpreted as
always requiring the version of the method that is enforced by the BRs at
issuance time.  However, this can cause the exact meaning of a CAA record to
change over time as the BRs evolve.  I don't think this is a big problem,
but wanted to note it.

The second issue is that it is possible that the numbering of the BR
validation methods could potentially change over time.  For that reason, I
think it might be reasonable to standardize on a label for each validation
method, that can be used in addition to the section number:


BR Section (BR v. 1.5.4)

Short Section

Validation method label


3.2.2.4.1

1

DomainContact


3.2.2.4.2

2

EmailOrSimilar


3.2.2.4.3

3

Phone


3.2.2.4.4

4

ConstructedEmail


3.2.2.4.5

5

DomainAuthorizationDocument


3.2.2.4.6

6

WebsiteChange


3.2.2.4.7

7

DNSChange


3.2.2.4.8

8

IPAddressLookup


3.2.2.4.9

9

TestCertificate


3.2.2.4.10

10

RandomValueInCertificate

 

Examples:

CAA 0 issue "ca.example.net; validation=3"                      # Call me
about all certificates

CAA 0 issue "ca.example.net; validation=Phone"             # Same as
previous example

CAA 0 issue "ca.example.net; validation=1,2,3,4,7,8,9,10"   # I don't like
DADs and website changes

CAA 0 issue "ca.example.net; validation=!5,6"                 # Same as
previous example.  Worth the trouble?


Account Identifier


 

This one is relatively straightforward, as the identifier is going to be
CA-specific anyway.  Use the "account" keyword:

CAA 0 issue "ca.example.net; account=8675309"

The format and values of the account specifier is up to the individual CA.


Acceptable Certificate Types


 

This one also seems to be relatively straightforward.  I've chosen to make
the categories disjoint, so if you're ok with more than one type, you have
to specify more than one.  Use the "type" keyword.

CAA 0 issue "ca.example.net; type=EV"                         # EV only

CAA 0 issue "ca.example.net; type=DV"                         # DV only

CAA 0 issue "ca.example.net; type=OV,EV"                   # No DV


Lack of Property Tag Value Criticality


 

Supporting the various properties is optional.  Unlike the CAA "issue"
property, these properties do not have to be ubiquitously supported to have
value, because Domain holders can restrict their issue records to only
include CAs that have publicly stated that they support the desired property
tags.

For example, if CAs A, B, and C support the "type=EV" tag, then the
following will prevent non-EV issuance:

CAA issue 0 "A.com; type=EV"

CAA issue 0 "B.com; type=EV"

CAA issue 0 "C.com; type=EV"

Unfortunately, this does scale poorly with a large number of CAs.

The problem is that RFC 6844 supports "Critical" for property tags (like
"issue"), but there is no way to mark a parameter tag is "Critical".  I
intend to bring this up with the IETF WG.

Any easy solution is to use reserved bit #1 for property tag criticality:


CAA issue 64 "A.com; type=EV"            # type=EV tag must be respected;
                                                                    # cannot
issue if you don't understand or enforce it.


 


Multiple Tags


 

Just for completeness, these individual features can also be used together:

CAA issue 0 "ca.example.com; type=EV validation=Phone account=8675309"