CAA iodef mailto

[Mark Gamache]

Hi,

Has there been talk about requirement mail be sent to the CAA IODEF email address on rejection? Obviously mail is not perfect, but it's pretty good at getting things done. 

The reason I ask is twofold. The obvious reason, if bad guys tries to get certs in my domain, is well understood. The second reason is that if something changes in a very large org, like mine, CAA records could start blocking cert requests. Depending on logging and other things, the failures may not be caught until there is an outage. Something like acme client may try and fail over and over until we have an outage. It sure would be nice to have a clear signal, controlled by my DNS and PKI teams, that the ACME client, run by some other team, is failing and they are about to have an outage. One might say, I am asking the CABF to solve my problem, but ultimately, many CABF rules are about making a framework to allow orgs to succeed safely, regardless of who might ultimately own an outcome.

Has this been considered? What would it take to get it considered, if not?

Thanks,

Mark Gamache

Interested Party 

[Mark Gamache]

Anyone?

---

From: Mark Gamache <ma...@markgamache.com>
Sent: Monday, March 31, 2025 2:00 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] CAA iodef mailto

 

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/MW5PR16MB4846E65CCCADBF8D0E85587BD1AD2%40MW5PR16MB4846.namprd16.prod.outlook.com.

[Martijn Katerbarg]

Hi Mark,

 

This was discussed during the previous Servercert meeting. While there was interest in adopting a requirement for this, a few potential issues were raised by having a requirement to follow iodef mailto URL schemes. Among this was the potential for a CA to be DDoS’ed on their mailserver, be blocked by spamfilters, and most critical, there’s a potential issue from a privacy / GDPR perspective.

In short: Just because there’s an email address within an iodef tag, doesn’t mean that the owner of that email address put it there himself. If such a recipient demands that a CA stops sending these emails, a CA could then be put in the position of having to violate either BR requirements, or violate the opt-out by such a recipient.

 

Having said that, it was discussed that a possible path forward could be to make this a requirement, but only for http/https URL schemes. That would allow any party who does want to receive notifications to implement such a mechanism on a pre-defined URL, without CAs running the risk of violating privacy laws.

Regards,

Martijn Katerbarg
Sectigo

 

From: Mark Gamache <ma...@markgamache.com>

Date: Friday, 18 April 2025 at 00:15
To: server...@groups.cabforum.org <server...@groups.cabforum.org>

Subject: [Servercert-wg] Re: CAA iodef mailto

Anyone? From: Mark Gamache <mark@ markgamache. com> Sent: Monday, March 31, 2025 2: 00 PM To: servercert-wg@ groups. cabforum. org <servercert-wg@ groups. cabforum. org> Subject: [Servercert-wg] CAA iodef mailto Hi, Has there been talk about

ZjQcmQRYFpfptBannerStart

This Message Is From an Untrusted Sender

You have not previously corresponded with this sender.

Report Suspicious

 

 

ZjQcmQRYFpfptBannerEnd

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/MW5PR16MB4846C5E320117FA065AA1B5CD1BC2%40MW5PR16MB4846.namprd16.prod.outlook.com.

[Mark Gamache]

I'd surely welcome some sort of https url for a webhook or such. I felt the mailto: was a bit old school, but it's what seemed to be the intent of the RFC. 

What does it take to get a design approved and a roadmap and timeline ?

Thanks,

Mark Gamache 

---

From: 'Martijn Katerbarg' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Friday, April 18, 2025 12:04 AM

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB6503CE4AAB7E4E272AA28C4DE3BF2%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Aaron Gable]

The CAA RFC refers to RFC 6546 for how a CA should submit an IODEF report to an http(s) URI. Unfortunately, that RFC defines a very large request-and-response protocol surface, including callback support, and transitively referencing RFCs 5070 and 6545 to define the (again, large and extensible) message format.

Reading these three documents, it is honestly unclear what behavior would actually be expected from a CA submitting an IODEF report via this protocol. I am curious if any CA has implemented this, and if so, what design and implementation decisions they made in the process.

I think if any CA were to be required to support this mechanism, it would first need to be profiled down to a manageable scope. Otherwise interoperability will be nigh impossible to achieve.

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/MW5PR16MB48464F54D2FBF0C72ADDFC14D1BF2%40MW5PR16MB4846.namprd16.prod.outlook.com.

[Kyle Duren]

I've seen one, a single report from Buypass CA in the recent past about a CAA failure, I think that's the only CA we've ever received an alert email from a root operator.

Kyle Duren
Edge Security Architect
Paranoids: Network Access and Identity

M 310 467 5183

      

Anyone?

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErf3fn6%2B-vUn2jNmWH4Eb7fQVn4j6j3_f%3DGdaxL%2B29T5fw%40mail.gmail.com.

[Aaron Gable]

Sorry, I was asking if any CA has implemented RFCs 6546, 5070, and 6545 in order to provide HTTP(S) notifications, not mailto: notifications.

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CALj9SO7pqJiocyayM00NtAri2dOrp2mL2dtPhQ562xRBBpvbgw%40mail.gmail.com.

[Martijn Katerbarg]

Thanks for pointing me to those RFCs Aaron. I was already wondering if we needed a specification for this. It would be best if all CAs followed the same standard for sending notifications, so that a Subscribers single end-point could process a message from any CA.  I may need to take a dive into these.

 

> What does it take to get a design approved and a roadmap and timeline ?

Essentially, proposed language by a member, two endorsing members, and then a discussion/voting period. However, there’s no roadmap or timeline that CABF can provide, until any voting period has concluded.

 

Regards,

Martijn

 

 

 

From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, 18 April 2025 at 18:38
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: Re: [E] Re: [Servercert-wg] Re: CAA iodef mailto

Sorry, I was asking if any CA has implemented RFCs 6546, 5070, and 6545 in order to provide HTTP(S) notifications, not mailto: notifications. Aaron On Fri, Apr 18, 2025 at 8: 53 AM 'Kyle Duren' via Server Certificate WG (CA/B Forum) <servercert-wg@ groups. cabforum. org>

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

 

ZjQcmQRYFpfptBannerEnd

Sorry, I was asking if any CA has implemented RFCs 6546, 5070, and 6545 in order to provide HTTP(S) notifications, not mailto: notifications.

 

Aaron

 

On Fri, Apr 18, 2025 at 8:53 AM 'Kyle Duren' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:

I've seen one, a single report from Buypass CA in the recent past about a CAA failure, I think that's the only CA we've ever received an alert email from a root operator.

 

Kyle Duren
Edge Security Architect
Paranoids: Network Access and Identity

M 310 467 5183

      

 

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnEre%2BT-Z%3DEWCK2n3fv05PeNGvymxBUhFioYWL%2BLRHj3pvrg%40mail.gmail.com.

[Mark Gamache]

I know I'd welcome a industry wide format. Something simple like a json payload with the time of the failure, the cert requested, preferably with the CSR, and maybe the source IP of the requestor and an account ID or such. 

---

From: 'Martijn Katerbarg' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Sent: Friday, April 18, 2025 10:54 AM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB65039E4C97761790F9C2CD59E3BF2%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Aaron Gable]

I agree that something simple like that would be nice (though I disagree that disclosing the source IP of the requestor would be a good privacy practice). But that's exactly the point I'm trying to make: the CAA RFC already standardizes the format a CA is supposed to use, and it's not something simple like that.

RFC 8659 "DNS Certification Authority Authorization (CAA) Resource Record", Section 4.4 "CAA iodef Property" says:

> The Incident Object Description Exchange Format (IODEF) [RFC7970] is used to present the incident report in machine-readable form.

and

> http or https: The IODEF report is submitted as a web service request to the HTTP address specified using the protocol specified in [RFC6546].

RFC 7970 "The Incident Object Description Exchange Format Version 2" is a 170-page document which defines dozens of different kinds of data that can be included in an IODEF report, all the way from basic data types like booleans and email addresses to more complex structures like the "Observable Class" which is supposed to be used to describe "a feature or phenomenon that can be observed or measured for the purposes of detecting malicious behavior". If a CA were to provide a proper IODEF report about the fact that CAA records had blocked an issuance request, what fields would they include in that report? What scheme should they use to generate the IncidentID? Since a CAA check happens at a single point in time, should the Incident's DetectTime, StartTime, EndTime, RecoveryTime, ReportTime, and GenerationTime all be identical, or should some of those fields be omitted? Should the report include an Assessment, an EventData, or both? Or should all of this be left unprofiled so that every CA can make its own set of decisions about how to construct the IODEF report?

Similarly, RFC 6546 "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS" defines an HTTP protocol with 6 request message types and 3 response message types. I believe that it makes the most sense for the CA to make a "Report" request, and for the receiving server to reply with an "Acknowledgement" response, but I'm not confident of that assessment and there may be other selections which also make sense. To define these request and response message types, it relies on "RID", a protocol which wraps IODEF and is defined in a separate RFC.

That document, RFC 6545 "Real-time Inter-network Defense (RID)" is an 80-page document which wraps IODEF with extensible schemas, signatures, versions, and more. The section describing a Report is fairly simple, so that's nice at least.

My point is that, if the CABF wants to require compliance with RFC 8659's description of how to submit an IODEF report to an http(s): URI, it would behoove us to know if anyone has actually implemented this whole stack of RFCs, what decisions they made about which fields to include, what adoption among their subscriber-base is like, and more. It would also probably be a good idea to take that information and turn it into a profile of these RFCs, so that CAs coming into compliance with them have a well-trod path to follow, instead of having to make all of these decisions in isolation.

Alternatively, if you really do want to pursue the path towards a simple JSON payload, I think that would be a matter for the IETF as an extension or change to the existing CAA RFC, rather than a matter for the CABF.

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/MW5PR16MB484645887828BDE8F0EAE02FD1BF2%40MW5PR16MB4846.namprd16.prod.outlook.com.

[Mark Gamache]

Thoughts on the use of RFC 8727, which is iodef as json? CABF would still need to decide on required and optional parameters. It's simple adjacent. 

FWIW, as the IP is either an attacker or I misconfigured my system, I don't see how the IP address would be a privacy issue. 

---

From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Sent: Friday, April 18, 2025 11:47 AM

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErfNZkPE_E5NdgxRq%2BGXRnTC_za-XR6ek2a4bfGqw0mXuQ%40mail.gmail.com.