[cabfpub] Continuing the discussion on CAA

Jeremy Rowley jeremy.rowley at digicert.com
Wed Oct 26 06:52:19 UTC 2016

I do think we are talking past each other, which is understandable because this idea was a pivot from the first one. Basically, I’d like a way for the domain owner to opt-out of CAA checks for performance reasons, which I think resolves the concerns you raised.


To put the idea in terms of the RFC:

 <https://tools.ietf.org/html/rfc6844#section-3> 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:


   {new} reverse <Reverse Processing> [; <name>=<value> ]:  The validation property entry authorizes Issuers to apply the policy set by the CAA record applies to all subordinate domains under the domain, effectively reversing the Certificate Authority Processing order described in [4]. 


As I mentioned before, the RFC is already established in a way that permits adding properties to the specification. This is an easy to way to match validation to the CAA record for those entities who are concerned with issuance times. Anyone wanting to ensure subdomains are separately delegated wouldn’t set the property.


Specific points:

I believe this is irrelevant. We're discussing scope of authority, not the presented information. DNS's scope of hierarchal authority flowing down involves delegating authority at each subordinate, which is why CAA works from the most authoritative scope (the fully qualified domain) and then works upwards.


{JR} I don’t think it’s irrelevant. We’re discussing how to distribute policy. CAA doesn’t have implications on DNS operations. 


 A simpler way to do this would simply have the base domain indicate whether the policy applies to all other domains. 


I appreciate your perspective, but I disagree. We (Google, the Internet community) have substantial experience in such 'top-down' policy expressions, via methods such as HSTS and HPKP, and we repeatedly receive concerns about that approach.


A concrete example of why I believe this is fundamentally a flawed design, and do not support it, is situations where 'example.com <http://example.com> ' delegates subdomains to different marketing companies, who are then responsible for hosting and providing the content on those subdomains. Expressing CAA in this 'top down' approach means that, for the 'base domain', you must express the union of all possible CAs. We know, empirically, this is not viable.


{JR} It is possible unless your name is Google, Microsoft, or some other large org. Government entities especially have a lot of domain names expressed in odd combinations. Using an express tag for validation lets the domain holder choose how to process the information, giving them control over the policy. It seems aligned with your goals of permitting domain owners to set policy. 


Further, I want to challenge your notion of 'base domain', which I know you mean in good intent, but for which I tried to highlight in my previous message is problematic in scope and determination. As you know, dependencies on the public suffix list are not at all desirable, in the general case, and there is substantial ambiguity and difference between information expressed in WHOIS (which I believe you're referring to, inasmuch as you mean 'registerable domain') and that expressed in DNS.


{JR} The CAA text doesn’t address this as is. Plus, the validation property only authorizes the issuer to rely on the CAA record already shown. It does not preclude standard CAA processing. For example:


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



   $ORIGIN domain.example.com
   .       CAA 0 validation issue "ca2.example.net"


CA1 could issue to example.com or domain.example.com based on the validation flag. CA2 could still issue to domain.example.com (based on the CAA record) but could not issue to example.com.


This is already permitted in CAA with wildcards so simply adding a tag that specifies “apply to all domains” would be easier (Indeed – the spec is designed for this). How about PHB adds a tag of “base-approval=1” as a flag to indicate all superior labels are considered approved IF the flag is set. If the flag is not set, validation would have to occur at each node.


I've tried to explain why I believe your proposal is technically unsound and unworkable, but perhaps we're simply not communicating. I do encourage you to re-read the CAA spec, however, because your description of wildcards and tags is something that is quite ambiguous and problematic, so it would help if you could be more precise in your terms.

{JR} Sorry, all I was referencing here was that PHB already designed the RFC to accept additional properties (one example is the issuewild property). I was also emphasizing that this is totally optional for CAA users. If the validation property is not included, domain processing would proceed as normal.


For example, your suggestion that PHB "add a tag" is, as explained on past discussions, unnecessary. In CAA, there are are 'parameter tag' (also called 'property tag'), such as 'issue', which are additive. That is, they expand the scope, not restrict it. Within a given 'issue' or 'issuewild' parameter tag, you can have issuer-parameters, but those are defined to further constrain the issuance, which again, is the opposite of what you intend.

{JR} Why couldn’t they permit additional issuers? Additional issues is not disallowed by the RFC. Although his examples expand the restrictions placed on issuance, the goal is really to give domain holders more control. This gives them more control.  


I'm trying to highlight that there are substantial technical concerns, and resolving them to accommodate what you propose would require significant IETF action, even if they were agreed upon as desirable, which I do not believe they are. Further, I do not believe it aligns with what we concretely and empirically know about the experience and desires of site operators, both with respect to CAA and in related policy expressions.


{JR} Then you really hould talk to more site operators. I don’t know of any (except maybe the browsers themselves) who want the CAs denying domain.example.com but allowing *.example.com. I know of lots who don’t want us looking up domain.example.com CAA records if they’ve already authorized all subordinate domains to example.com. I’m not saying this is the best way, but at least it’s a solution on how people can opt out (on a technical basis) of CAA checking for every cert. I’m sure you have a better idea up your sleeve on how to address the issue, and I’d love to hear it. 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161026/aab43ea7/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161026/aab43ea7/attachment-0001.p7s>

More information about the Public mailing list