Subject: [lamps] CAA tags

From: Tim Hollebeek <[email-masked]>
Date: Mon, 18 Dec 2017 17:41:45 +0000

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"

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 18 Dec 2017 11:30:40 -0800

I'm following up your the related validation@cabforum thread at
https://cabforum.org/pipermail/validation/2017-December/000686.html,
hoping to merge the streams a little bit. :-)

On 12/18/2017 11:10 AM, Tim Hollebeek via Validation wrote:
> I personally find OIDs very hard for non-technical users to grasp.

This is a good point, although most users should be using a CAA record
generator, which can help with this.

> readable text labels, like Validation=Phone?

My issue with validation=phone is that it is not precise enough; there's
one version of validation by phone defined in the BRs today, but what if
that changes significantly? One could solve this by defining a versioned
validation method, e.g. validation=phone-01, with an IANA registry to
register new ones as requirements change.

However, there does seem to be some interest in embedding information
about validation methods in certificates. It would be nice if there was
a correspondence between the namespace used in CAA and the one used in
certificates.

> I think account and account-uri are complimentary approaches.  I agree
> that CAs need the freedom to put whatever they want on the right hand
> side of these, and many CAs have existing customer identification
> schemes that are not URIs, so the account-uri field cannot be used.

It's easy to define a URI mapping for an existing account identifier.
For instance, if customers have a numeric id 123456, the CA can specify
that the corresponding account-uri is
https://ca.example.net/accounts/123456. There's no requirement that
account-uris are fetchable.

It seems inefficient to define the same mechanism under two different
names in two different places (account vs account-uri), and I think is
likely to lead to user error.

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 18 Dec 2017 20:10:53 +0000

> My issue with validation=phone is that it is not precise enough; there's
one
> version of validation by phone defined in the BRs today, but what if that
> changes significantly? One could solve this by defining a versioned
validation
> method, e.g. validation=phone-01, with an IANA registry to register new
ones
> as requirements change.

The lack of precision bothered me a bit too when I was proposing it,
especially since some people have discussed breaking up some of the 
larger catch-all ones.  I like the version number, but I think we have to be

a bit careful.  Is the version just a minimum version?  If I have CAA set to

validation=phone-01, do I have to update my CAA record every time the 
BR validation methods are changed?  How big of a change requires revving 
the version number of the validation method?

Should the BR version number be used instead?  E.g. validation=phone-1.5.4?
This might make more sense as the BR version number does get bumped on
every validation rev (and non-validation rev ...).

> about validation methods in certificates. It would be nice if there was a
> correspondence between the namespace used in CAA and the one used in
> certificates.

That would be nice.  Maybe an IANA registry for validation methods might
make sense, but I'm unfamiliar with how easy/difficult that is to set up/
modify.

> For instance, if customers have a numeric id 123456, the CA can specify
that
> the corresponding account-uri is https://ca.example.net/accounts/123456.
> There's no requirement that account-uris are fetchable.

I get that, but a URI is longer and more complicated.  Quirin's research
shows that a significant fraction of CAA users CANNOT SPELL THEIR CA'S
NAME.  I shudder to think how they will manage to mangle a URI ...

-Tim

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 18 Dec 2017 15:42:05 -0500

> make sense, but I'm unfamiliar with how easy/difficult that is to set up/

It'd be great if there was a spec writeup for discussion - or is this a
pre-spec seeds of thoughts?

I think Jacob's suggestion of OIDs is not at all unreasonable, and avoids
the ambiguities you raise and allows them to be addressed by policy in the
Forum.

> NAME.  I shudder to think how they will manage to mangle a URI ...

I also agree with Jacob's suggestion here, and prefer a single, canonical
representation.

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 18 Dec 2017 20:45:45 +0000

Pre-spec for discussion.  It’s current status is “I sat down for an hour, reviewed meeting minutes and read some stuff, and circulated some notes”.

-Tim

From: Ryan Sleevi [mailto:[email-masked]] 
Sent: Monday, December 18, 2017 1:42 PM
To: Tim Hollebeek <[email-masked]>
Cc: Jacob Hoffman-Andrews <[email-masked]>; [email-masked]
Subject: Re: [lamps] CAA tags

one
validation
ones

It'd be great if there was a spec writeup for discussion - or is this a pre-spec seeds of thoughts?

I think Jacob's suggestion of OIDs is not at all unreasonable, and avoids the ambiguities you raise and allows them to be addressed by policy in the Forum.

that

I also agree with Jacob's suggestion here, and prefer a single, canonical representation.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 18 Dec 2017 22:02:05 +0000

On 18/12/17 20:42, Ryan Sleevi wrote:
<snip>
> I think Jacob's suggestion of OIDs is not at all unreasonable, and 
> avoids the ambiguities you raise and allows them to be addressed by 
> policy in the Forum.

We had policy OIDs in early versions of the I-D [1] that later became 
RFC6844, but we had to strip this out in favour of domain names when the 
document was adopted by PKIX.  WG consensus and all that.

I'm not sure what that decision might mean for any other proposals to 
use OIDs with CAA.

[1] https://www.ietf.org/archive/id/draft-hallambaker-donotissue-04.txt

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Dec 2017 01:23:57 -0500

We did indeed start with OIDs. But the reason I agreed to Domain Names was
that the suggestion (I seem to remember it was Paul Hoffman) was obviously
the right one.

Most of the things people want to do with tags can be done with domain
names. More importantly, it can be done outside the IETF. If you want 'any
EV' issuer, get the CABForum to approve ev.cabforum.com for the purpose.

Restricting to specific validation methods is interesting and might be a
justified use for the criticality flag.

The other point to ponder is how a server that needs a cert discovers where
the cert issuing service is. The idea was that if the CAA record specifies
chosenca.com, a server would then be able to use that information to work
out how to get a cert and automate the whole process.

Remember that at the time, there was this idea that DNS records should not
make use of prefixes and should not make use of additional parsing beyond
DNS record markers. At this point, I think we can safely ignore both
notions as broken and if I was to do it again would suggest it just be a
TXT type record. But we can't that's water under the bridge now, sorry.

On Mon, Dec 18, 2017 at 5:02 PM, Rob Stradling <[email-masked]>
wrote:

> I'm not sure what that decision might mean for any other proposals to use
> OIDs with CAA.
>
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Dec 2017 12:13:22 +0000

Hiya,

I've not been following this closely but since you
said:

On 18/12/17 20:45, Tim Hollebeek wrote:
> Pre-spec for discussion.  It’s current status is “I sat down for an
> hour, reviewed meeting minutes and read some stuff, and circulated
> some notes”.
I guess it may be ok to throw in a requirement to
keep an aspect of the status quo:

I'd like to ensure it remains possible for a whole
bunch of DNS domains to use the same CAA RR value
and for that to continue to make sense. I've no
problem if optional things can be added that are
domain-specific so long as I don't have to create
custom CAA values for every domain.

My reason for wanting that is that I deal with
sets of domains who can all currently sensibly use
the same CAA value and that's easy to handle. If
I had to go changing the value for each, esp if
that had to be re-done regularly, or even worse,
sporadically, that'd be a PITA.

Apologies for the interruption if this is already
taken as a given, but I wasn't sure based on the
recent mails about phone numbers etc.

Thanks,
S.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 19 Dec 2017 09:25:54 -0500

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 <[email-masked]>
wrote:

> 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
>
>
>
> ------------------------------------------------------------
> ------------------------------------------------------------
> -------------------------------
> 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:
>
>    4. Allow CAA record creation tools to support creating CAA records
>    that contain properties that have been standardized
>
> History
>
>
>
> validation methods, an account identifier, certificate types (DV/OV/EV),
> and ability to specify a brand.
>
>
> Method of Adoption
>
>
>
> CA could implement, they don’t necessarily have to exist in a standards
> best to include them in the Baseline Requirements as an optional feature
> CAs MAY implement.
>
> I’m starting with this one because I’m going to argue it isn’t necessary.
> also existing.  I’d suggest that CAs that maintain multiple brands simply
> certs.example.com               CAA 0 issue “megaca.com”
>
> catlover.example.com         CAA 0 issue “certsforcats.com”    #
> “validation” tag.
> 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.
>
> *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
>
> 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
> CA-specific anyway.  Use the “account” keyword:
>
> CAA 0 issue “ca.example.net; account=8675309”
>
> 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
> Supporting the various properties is optional.  Unlike the CAA “issue”
> 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
> CAA issue 0 “A.com; type=EV”
>
> CAA issue 0 “B.com; type=EV”
>
> CAA issue 0 “C.com; type=EV”
>
> 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
> 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
>
>
>
> CAA issue 0 “ca.example.com; type=EV validation=Phone account=8675309”
>
>
>
>
>

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 19 Dec 2017 14:47:06 +0000

If you don't want to use these tags, you don't have to.  They're purely optional and completely backwards compatible.  They simply transmit additional information to the CA about the desired certificate.

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Tuesday, December 19, 2017 5:13 AM
> Cc: [email-masked]
> I guess it may be ok to throw in a requirement to keep an aspect of the status
> quo:
> 
> I'd like to ensure it remains possible for a whole bunch of DNS domains to use
> the same CAA RR value and for that to continue to make sense. I've no
> problem if optional things can be added that are domain-specific so long as I
> don't have to create custom CAA values for every domain.
> 
> My reason for wanting that is that I deal with sets of domains who can all
> currently sensibly use the same CAA value and that's easy to handle. If I had to
> go changing the value for each, esp if that had to be re-done regularly, or even
> worse, sporadically, that'd be a PITA.
> 
> Apologies for the interruption if this is already taken as a given, but I wasn't
> sure based on the recent mails about phone numbers etc.
> 
> Thanks,
> S.

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 19 Dec 2017 14:50:44 +0000

As I noted in the preface to my initial email in this thread [1], one other person has pointed out the same thing to me.  I noted that not only is this an option, but it solves two problems with the original proposal, so I’m personally leaning towards it.  We’ll see what other CAs think.

CAA issue 0 "example.com <http://example.com> "

CAA issue 0 "example.net <http://example.net> "

On Mon, Dec 18, 2017 at 12:41 PM, Tim Hollebeek <[email-masked] <mailto:[email-masked]> > wrote:

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:

CAA 0 issue “a.example.com <http://a.example.com> ”

CAA 0 issue “b.example.com <http://b.example.com> ”

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Dec 2017 14:53:57 +0000

On 19/12/17 14:47, Tim Hollebeek wrote:
> If you don't want to use these tags, you don't have to.  They're
> purely optional and completely backwards compatible.  They simply
> transmit additional information to the CA about the desired
> certificate.

Great, as long as that stays the same, I'm happy to
go back to watching from the side-lines:-)

Thanks,
S.

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 19 Dec 2017 15:10:24 +0000

Hmm, domain names as tags is an interesting idea I had not considered.  I’ll keep it in mind.  Thanks.

-Tim

From: Spasm [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Monday, December 18, 2017 11:24 PM
To: Rob Stradling <[email-masked]>
Cc: SPASM <[email-masked]>
Subject: Re: [lamps] CAA tags

We did indeed start with OIDs. But the reason I agreed to Domain Names was that the suggestion (I seem to remember it was Paul Hoffman) was obviously the right one. 

Most of the things people want to do with tags can be done with domain names. More importantly, it can be done outside the IETF. If you want 'any EV' issuer, get the CABForum to approve ev.cabforum.com <http://ev.cabforum.com>  for the purpose.

Restricting to specific validation methods is interesting and might be a justified use for the criticality flag. 

The other point to ponder is how a server that needs a cert discovers where the cert issuing service is. The idea was that if the CAA record specifies chosenca.com <http://chosenca.com> , a server would then be able to use that information to work out how to get a cert and automate the whole process.

Remember that at the time, there was this idea that DNS records should not make use of prefixes and should not make use of additional parsing beyond DNS record markers. At this point, I think we can safely ignore both notions as broken and if I was to do it again would suggest it just be a TXT type record. But we can't that's water under the bridge now, sorry.

 

On Mon, Dec 18, 2017 at 5:02 PM, Rob Stradling <[email-masked] <mailto:[email-masked]> > wrote:

We had policy OIDs in early versions of the I-D [1] that later became RFC6844, but we had to strip this out in favour of domain names when the document was adopted by PKIX.  WG consensus and all that.

I'm not sure what that decision might mean for any other proposals to use OIDs with CAA.

_______________________________________________
Spasm mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/spasm

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 19 Dec 2017 14:15:50 -0500

Thanks for clarifying. From your original e-mail, it wasn't clear if you
were taking a particular position on the property tags vs parameters,
and/or what considerations fed into such discussions. That's where having
the problem statement (or 'explainer', as its called in some SDO circles)
and use cases is useful to explore these tradeoffs :)

On Tue, Dec 19, 2017 at 9:50 AM, Tim Hollebeek <[email-masked]>
wrote:

> As I noted in the preface to my initial email in this thread [1], one
> other person has pointed out the same thing to me.  I noted that not only
> is this an option, but it solves two problems with the original proposal,
> so I’m personally leaning towards it.  We’ll see what other CAs think.
>
>
>
> On Mon, Dec 18, 2017 at 12:41 PM, Tim Hollebeek <
> [email-masked]> wrote:
>

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 19 Dec 2017 21:54:30 +0000

Yup.  That’s why I’m not writing a spec right now.  I’m always open to reasonable feedback on anything that makes my proposals better.  I rarely get things entirely right the first time!

-Tim

From: Ryan Sleevi [mailto:[email-masked]] 
Sent: Tuesday, December 19, 2017 12:16 PM
To: Tim Hollebeek <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; Jacob Hoffman-Andrews <[email-masked]>; [email-masked]
Subject: Re: [lamps] CAA tags

Thanks for clarifying. From your original e-mail, it wasn't clear if you were taking a particular position on the property tags vs parameters, and/or what considerations fed into such discussions. That's where having the problem statement (or 'explainer', as its called in some SDO circles) and use cases is useful to explore these tradeoffs :)

On Tue, Dec 19, 2017 at 9:50 AM, Tim Hollebeek <[email-masked] <mailto:[email-masked]> > wrote:

CAA 0 issue “ <http://a.example.com> a.example.com”

CAA 0 issue “ <http://b.example.com> b.example.com”