Would it be desirable to add a field to the CAA record which specifies a list of authorized agent keys? It would be very useful to restrict HTTP/TLS validation to specific agents and prevent the challenge process from getting MITMed.
2 Likes
Yes, RFC 8657 provides essentially this. It's supported in the Let's Encrypt staging environment, and we hope to make it available in production soon.
6 Likes
Ah, had seen the RFC previously for validationmethods support, missed that it had accounturi as well.
Is there a timeline for when it would become available in production? Happy to contribute to help move it along as well.
2 Likes
Unfortunately, there’s no timeline - it’s been much delayed by other priorities - but I’ll be very excited to see it enabled in production.
6 Likes
A few months ago when the topic last came up here, I at least got the impression that one of the main things that needed to happen was a lot of testing and fleshing out all the corner cases of the specification. They need to ensure that they're dealing with ambiguous, malformed, or multiple CAA entries exactly correctly, because issuing a certificate in violation of a CAA record is a Big Deal of a problem (for good reason).
So if you wanted to contribute some time (rather than, say, money; I'm not sure which you meant) to trying to shake out all the details and building a test suite to run against the staging environment, I suspect that's the only thing that might be able to help make the process go faster. Though I suppose it's possible that a large enough monetary contribution might influence the engineers' priority list too. 
6 Likes
I think it'd be safe to do you follow our format exactly or not sign approach as it's opt-in, like duplicate will allow sign if allowed in both record or just refused to sign at all.
2 Likes
Thanks! Planning to start writing some test suites. Can you also point me towards where this feature is implemented (if it's open source)?
2 Likes
The core of Boulder's implementation for this is here: boulder/caa.go at main · letsencrypt/boulder · GitHub
5 Likes
I kinda wish RFC8657 's validation method were able to point some blessed methods on CA/B BR, not acme method, with some plain-text alias like (like http for both acme and non-acme change site as request, and dns for 4.3.7) it would be much useful to adapted by CAs that have non-acme endpoint. but not sure RFC can written to read CA/B for flages. like CAB-19 for baseline 3.2.2.4.19, (agreed upon change on http -acme)
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.