CAA reporting support and tests?

[Hanno Böck]

Hi,

I was wondering how a CAA reporting endpoint should react and wanted to
test it. However none of the CAs I tested seems to support reporting
yet.

Is anyone aware of a CA that does CAA reporting? (either via mail or
https or both.)
If no reporting on a live CA is in place is at least anyone aware of
any kind of available test that is able to generate CAA reports?

Also I'm wondering if there are any plans to have a requirement for CAA
reporting support in the future. The cabforum ballot [1] says that
reporting "SHOULD" be done.



[1]
https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Matthew Hardeman]

Has there been any serious discussion of the potential benefit of CAA reporting for certificate issuance attempts?

I'm aware of what the spec says and the SHOULD language, etc...

I'm not a CA and don't represent one.

I do, however, think that it's easier to get buy-in for changes to CA infrastructure when there is a strong showing for cost/benefit relationship.

In a post-CT world, issuances which occur will be easily detected quite promptly.

I am unsure of the value of a report issuing for a failed issuance attempt. "Oh, yea, that wasn't me. Someone's looking to attack." How does that help? One should always assume that one is under attack. Perhaps it allows you to identify an internal party attempting to get a certificate issued and allows you to work with that party to correctly get a certificate issued, but wouldn't that legitimate inside party have reached out internally anyway when they encountered a problem?

I'm just not sure I understand the point of the reporting in terms of deriving real security value.

I think it behooves the community, in selecting items to advance for mandatory compliance within the CA space, to choose the requirements imposed carefully and with a view to deriving real objective security value.

[Jakob Bohm]

On 26/09/2017 01:03, Andrew wrote:

> The BRs are indeed a bit ambiguous on this point, but my interpretation of this statement
>
>> CAs MUST document potential issuances that were prevented by a CAA record in sufficient detail to provide feedback to the CAB Forum on the circumstances, and SHOULD dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s), if present
>
> is that the reports should only be sent in a situation where a certificate _would_ have been issued if not for the CAA records. In other words, all other security measures intended to prevent misissuance failed, and if not for the presence of the CAA record a valid certificate for your domain would have been issued to a potentially malicious actor. In that situation, you'd definitely want to be informed so you can investigate what allowed the attacker to get that far along in the process.
>
> That's my understanding anyway.
>

Alternatively, you might want to adjust your CAA record if that was
actually a legitimate request. This is especially handy if the CA only
communicates a generic "rejected" message to the applicant in your
organization (which might even be the person managing the CAA record and
receiving the report).



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Gervase Markham]

On 26/09/17 00:03, Andrew wrote:
> is that the reports should only be sent in a situation where a
> certificate _would_ have been issued if not for the CAA records.

I'd say that's right. I'd think that by far the more common use case
would be internal policy enforcement at a company rather than detecting
a 3rd party attacker. And given that it's often just "send an email",
one hopes the iodef might not be too onerous for CAs to implement. I
believe we scoped it down to only having to support http: and mailto:.

Gerv