Thank you all for the good discussion. It seems like a solid discussion and reasoning towards removing the paragraph. I'll post a new version soon..
Best regards, Kathleen On Wed, Jul 29, 2020 at 12:39 PM Ben Schwartz <[email protected]> wrote: > Thanks for the explanation. I certainly agree that the paragraph as > written is incorrect: fetching the CAA record from the DNS, and attempting > to use it for validation, is not possible. Removing the paragraph seems > fine to me. > > My point was mostly that CAA transparency (even without any automation) > could be interesting, but this draft probably isn't the place to speculate > on that. > > On Wed, Jul 29, 2020 at 11:19 AM Ryan Sleevi <[email protected]> wrote: > >> Ben: This text was intended towards auditors, and is indeed part of the >> ongoing logging requirements imposed on CA. While it’s easy to imagine a >> hypothetical world of CAA transparency and talk of it as if it was a thing, >> there are a number of real and practical operational challenges that make >> it more than “just” a log, particularly given the time-bounded nature of >> DNSSEC validity and cryptographic material. >> >> The text in the draft, as is, is problematic, because that’s not been the >> goal of CAA, and using it in such a manner, particularly clients, would be >> actively harmful to the security value and deployability of CAA, and >> further makes migration CAs unnecessarily difficult. This was a hugely >> contentious barrier towards the deployment and requirement of CAA support >> by CAs, and would have obvious lasting security harm. >> >> Concretely, imagine at Time 0, my CAA record says “foo.example”, and a >> certificate with a validity period of 100 is issued. At Time 10, I cease >> doing new business with Foo CA, and transition to Bar CA, with CAA record >> of “bar.example” >> >> If clients check CAA, I would have to continue to permit Foo to be able >> to issue new certificates from T=10 to T=100 in order to continue to use my >> existing certificates. Further, I would have no technical means of >> disclaiming or proving any misissuance; e.g.. due to Foo using validation >> methods my organization did not wish to use, because my organization could >> not adequately secure them. In such a world, it would be “my” fault, while >> CAA provided a way to shift that burden to the CA performing the validation. >> >> This doomsday scenario doesn’t even require “most” clients to do so; just >> “enough” and the interoperability risk of CAA would be too great and the >> only obvious answer would be to not deploy it. >> >> In code signing, this is even more pronounced, because although the >> validity period is T=0 to T=100, code signing that delegates to third party >> CAs, as opposed to directly administered by the vendor, tends to >> counter-sign such signatures with a timestamp, so that the signed artifact >> can be used outside of its validity period. If the counter-signer checked >> CAA, you “only” have to worry about keeping CAA around for [T=10, T=100], >> but if the client verified CAA, you’d have to keep it around for [T=10, >> T=infinity] in order to keep that artifact valid. >> >> As Roland states, CAA is between a site, the CA, and whomever supervises >> that CA (e.g. auditors, supervisory bodies, etc). It provides a form of >> dispute resolution about whether a certificate was authorized at the time >> it was issued, in a consistent and interoperable way. The logs maintained >> by CAs are primarily there to aid in that direct dispute resolution, which >> is an inherently fuzzy and human process for what is expected to be a truly >> exceptional situation, and anything more generic/more broadly would require >> significantly greater complexity and design before it could be said to meet >> any verification goals. >> >> I support the paragraphs removal. >> >> On Tue, Jul 28, 2020 at 4:12 PM Ben Schwartz <bemasc= >> [email protected]> wrote: >> >>> RFC 6844 Section 4.1 points out that logged DNSSEC-signed CAA records >>> can be used when auditing CAs for mis-issuance. The current draft says >>> "CAA helps as anyone .... can verify that the CA used has been authorized", >>> which is true, but only if "anyone" has access to a log of the signed CAA >>> records used by the CA, and the domain is DNSSEC-signed. >>> >>> I would like it if CAs published such logs, but I don't know whether it >>> is a common practice. >>> >>> On Tue, Jul 28, 2020 at 3:58 PM <[email protected]> wrote: >>> >>>> Roland, >>>> >>>> >>>> >>>> Thank you, that’s very helpful Any other opinions? I’m very happy to >>>> delete with consensus and appreciate the reviews on this particular issue >>>> as well as on the draft. >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Kathleen >>>> >>>> >>>> >>>> *From:* Roland Shoemaker <[email protected]> >>>> *Sent:* Tuesday, July 28, 2020 3:27 PM >>>> *To:* Kathleen Moriarty >>>> *Cc:* Carl Mehner; Moriarty, Kathleen; IETF ACME >>>> *Subject:* Re: [Acme] CAA in draft-ietf-acme-client-01.txt >>>> >>>> >>>> >>>> [EXTERNAL EMAIL] >>>> >>>> I think the disconnect here is between CAs and Relying Applications >>>> (i.e. browsers) using CAA. The CA should use CAA to validate if they have >>>> authority to issue, but the relying application must not because the CAA >>>> records are only applicable at the time of issuance and there is no >>>> guarantee that the current CAA records may match the records that were >>>> present in the past (i.e. I may set my CAA record to allow "example-ca", >>>> issue a certificate, and then set my CAA record to an empty string to >>>> prevent issuance from anyone, the check is valid at the time of issuance, >>>> but anyone trying to do post-issuance validation would fail since the >>>> record has changed). >>>> >>>> >>>> >>>> I would support removing the paragraph. >>>> >>>> >>>> >>>> On Tue, Jul 28, 2020 at 7:57 AM Kathleen Moriarty < >>>> [email protected]> wrote: >>>> >>>> Hello Carl, >>>> >>>> >>>> >>>> Thank you for your review and I apologize for my extremely tardy >>>> response. >>>> >>>> >>>> >>>> On Mon, May 18, 2020 at 11:41 AM Carl Mehner <[email protected]> wrote: >>>> >>>> Looking at the latest draft for acme-client, I noticed that it mentions >>>> CAA: >>>> CAA helps as anyone verifying a certificate used for code signing can >>>> verify that the CA used has been authorized to issue certificates for >>>> that organization. >>>> >>>> However, in the CAA RFC it states: >>>> Relying Applications MUST >>>> NOT use CAA records as part of certificate validation. >>>> >>>> I propose removing the statement in acme-client about CAA that is >>>> quoted above. >>>> >>>> >>>> >>>> I recall having gone through this conversation before to wind up where >>>> the draft is now. RFC8555 has the following: >>>> >>>> caaIdentities (optional, array of string): The hostnames that the >>>> >>>> ACME server recognizes as referring to itself for the purposes of >>>> >>>> CAA record validation as defined in [RFC6844 >>>> <https://tools.ietf..org/html/rfc6844>]. Each string MUST >>>> >>>> represent the same sequence of ASCII code points that the server >>>> >>>> will expect to see as the "Issuer Domain Name" in a CAA issue or >>>> >>>> issuewild property tag. This allows clients to determine the >>>> >>>> correct issuer domain name to use when configuring CAA records. >>>> >>>> Section 9.7.8 has the following: >>>> >>>> Validation methods do not have to be compatible with ACME in order to >>>> >>>> be registered. For example, a CA might wish to register a validation >>>> >>>> method to support its use with the ACME extensions to CAA [ACME-CAA >>>> <https://tools.ietf.org/html/rfc8555#ref-ACME-CAA>]. >>>> >>>> >>>> >>>> Section 11.2 has the following: >>>> >>>> An ACME-based CA must only use a resolver if it trusts the resolver >>>> >>>> and every component of the network route by which it is accessed. >>>> >>>> Therefore, it is RECOMMENDED that ACME-based CAs operate their own >>>> >>>> DNSSEC-validating resolvers within their trusted network and use >>>> >>>> these resolvers both for CAA record lookups and all record lookups in >>>> >>>> furtherance of a challenge scheme (A, AAAA, TXT, etc.). >>>> >>>> >>>> >>>> As you point out, https://tools.ietf.org/html/rfc6844 >>>> <https://tools.ietf...org/html/rfc6844>, advises against its use. >>>> >>>> >>>> >>>> I am happy to edit to consensus. If a change is needed, I can turn >>>> that around quickly. >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Kathleen >>>> >>>> >>>> >>>> -carl mehner >>>> >>>> _______________________________________________ >>>> Acme mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/acme >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Kathleen >>>> >>>> _______________________________________________ >>>> Acme mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/acme >>>> >>>> _______________________________________________ >>>> Acme mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/acme >>>> >>> _______________________________________________ >>> Acme mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/acme >>> >> -- Best regards, Kathleen
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
