Boulder: Wildcard certs allowed via dns? (CAA 128 issuewild "letsencrypt.org")

[Darkspirit]

Hey, I watched https://www.youtube.com/watch?v=lcCAU8gOU6Y
where April King from Mozilla said, you can't allow wildcard certs, because some providers give their customers a subdomain, where they can do what they want.

Then what do you think about an explicit whitelist?
Only issue a wildcard cert, if the CAA record is set with the "Critical bit" and if the acme challenge is done via dns:
example.com. CAA 1 issue "letsencrypt.org"
example.com. CAA 1 issuewild "letsencrypt.org"
_acme-challenge.example.com TXT

Futher, you could demand the use of DNSSEC as incentive. (Would be the best possible option.)

https://tools.ietf.org/html/rfc6844#section-3 (CAA)

I have read the referred tickets from here https://github.com/certbot/certbot/issues/345

[tdelmas]

I think you meant
example.com. CAA 128 issue "letsencrypt.org"
example.com. CAA 128 issuewild "letsencrypt.org"
(as noticed here https://community.letsencrypt.org/t/caa-setup-for-lets-encrypt/9893/6 )

[Darkspirit]

Yes you are right. 128 is correct to set the critical flag.
https://tools.ietf.org/html/rfc6844#page-6

In the following example, the property 'tbs' is flagged as critical.
$ORIGIN example.com
. CAA 0 issue "ca.example.net; policy=ev"

. CAA 128 tbs "Unknown"

https://github.com/hlandauf/boulder/commit/fdd4a27848a875b0dcefdf6884d078cc8e8181c3
https://github.com/letsencrypt/boulder/issues/1436#issuecomment-175923224

The RFC is kind of annoying on this. It indicates that the critical flag is set if bit 0 is 1 (which is 128 decimal). Most implementors (looking at Boulder logs for people who have issued so far with critical CAA records) have misinterpreted this as setting the flag == 1 as critical, which actually means setting bit 7 to 1. To be truly spec compliant we should only treat flag == 128 as critical, but in reality this will break a lot of peoples usage. Since CAA only has one version, and the rest of the flag bits are reserved for future versions I think we are safe (for now) keeping this behavior and perhaps adding a comment explaining the deviation from the spec.

So currently 128 (and 1 for compatibility reasons and against the RFC) are handled as critical flag by Letsencrypt.

---

@bhushan5640 (https://github.com/ssllabs/ssllabs-scan/issues/274)
Please add this your SSLLabs' CAA check: 0=critical flag not set, 128=critial flag set. If someone has "1" here please return a warning, that they should use 128 to set the critical flag.
And, if I understand it correcly, you should display the green bar only if the CAA policy is enforced by setting the critical flag.

https://tools.ietf.org/html/rfc6844#page-9

Bit 0, Issuer Critical Flag: If the value is set to '1', the
critical flag is asserted and the property MUST be understood
if the CAA record is to be correctly processed by a certificate
issuer.
A Certification Authority MUST NOT issue certificates for any
Domain that contains a CAA critical property for an unknown or
unsupported property tag that for which the issuer critical
flag is set.

[bhushan5640]

@TerraX-net I suppose The critical flag in CAA, like the critical flag in x509 extensions, means only "error out if you don't understand this." Adding the critical flag to CAA types that are part of the base RFC (like issue) has no effect.

as explained here https://community.letsencrypt.org/t/caa-setup-for-lets-encrypt/9893/3

[Darkspirit]

@bhushan5640 Even though you are right,
@tdelmas pointed out following the RFC would be nice, maybe for educational purposes. We don't know in which way that RFC could get extended in the future. Maybe even browsers/addons could use that flag as signal to enforce that policy on browser side. Personally, I've changed '1' to '0' for now.

[rolandshoemaker]

Closing as a dupe of #21.