Re: [lamps] CAA tags

[Ryan Sleevi <[e-mail]>]

Tim,

>From a design consideration, if/as you look to write this up, it would be
useful to understand why you pursued the route of issuer-specific
parameters, rather than as new properties.

That is, why is the set of policy not

CAA issue 0 "example.com"
CAA issue 0 "example.net"
CAA validation 128 "type=EV method=1,2,3,4"

Which limits issuance to example.com and example.net, iff the validation
method of domain control employs methods 1, 2, 3, or 4, and the resultant
process uses the EV process? [*]

This obviously precludes the notion of 'account' - but I think that's
illustrative of the point; something like 'account' is inherently
CA-specific, while the validation methods or types are CA agnostic.

The benefit of this, for a Subscriber, is they might omit the publication
of an issue tag, thus not constraining per-CA, but still scoping the
validation methods.

Understandably, this design could also be accounted for with the CABForum
declaring some pseudo-domain to express such CA-agnostic properties, such
as:

CAA issue 0 "example.com; type=DV,EV method=1,2,3,4"        # If example.com
is issuing, support for both DV and EV, using methods 1-4
CAA issue 0 "validation.cabforum.org; type=EV method=1,2,3" # Otherwise,
support for EV only using methods 1-3

There are both strengths and weaknesses of both proposals, so it'd be great
to see a discussion about the problem statement and desired workflows.

[*] I provide these for simplicity of typing - but I think any restriction
of both 'type' and 'method' needs to be versioned, as the CABF documents do
change

On Mon, Dec 18, 2017 at 12:41 PM, Tim Hollebeek <[e-mail]>
wrote:

> 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”
>
>
>
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>
>