Repository: letsencrypt/boulder (Go)

Issue:
CAA issuemail property tag support
Boulder [does not currently handle `issuemail` property tag](https://github.com/letsencrypt/boulder/blob/8b532f127e1266a072342cba2d2c4996dc64e967/va/caa.go#L323) as defined in [RFC 9495](https://www.rfc-editor.org/rfc/rfc9495.html).

Consider handling it in a similar [way how `iodef` is handled now](https://github.com/letsencrypt/boulder/blob/8b532f127e1266a072342cba2d2c4996dc64e967/va/caa.go#L329) for compatibility with domains that will define `issuemail` with critical flag set.








Discussion:
Hi,

You're correct that we do not (yet) have support for RFC 9495, but may in the future. Can you explain a little bit about your use case for this please?. 

Currently we implement the CAA tags as defined by [Baseline Requirements section 3.2.2.8 CAA Records](https://github.com/cabforum/servercert/blob/main/docs/BR.md#3228-caa-records). 
> ...
> When processing CAA records, CAs MUST process the `issue`, `issuewild`, and `iodef` property tags as specified in [RFC 8659](https://datatracker.ietf.org/doc/html/rfc8659), although they are not required to act on the contents of the iodef property tag. Additional property tags MAY be supported
> ...

Dziękuję
> Can you explain a little bit about your use case for this please?.

Was wondering if it's possible today to define `issuemail` with critical flag set for domain and chosen CA (other than Let's Encrypt) and still be able to use Let's Encrypt certs for server certs in the same domain. But as I understand this would block server certs generation by LE because of unsupported `issuemail` flagged as critical.


You don't have to mark your issuemail critical if you don't want to.  In fact I'd recommend not doing so until it is widely supported.

Also, the correct BR document for S/MIME is the new S/MIME BRs, which now explain how CAA will work in the S/MIME ecosystem:

https://cabforum.org/smime-br/
https://www.linkedin.com/pulse/cabrowser-forum-ballot-extend-caa-smime-stephen-davidson-17txe
> In fact I'd recommend not doing so until it is widely supported.

Consider handling `issuemail` in Boulder as described above.
Also, feel free to reach out to us if you want additional advice around RFC 9495 and the S/MIME BRs, we know them quite well (the author of RFC 9495 works for me and the S/MIME WG chair works with me).
I think this is a reasonable request -- Let's Encrypt certainly won't be processing issuemail tags, but we can recognize them so that we don't bail out when someone has one set with a critical bit.
FYI, #7307 is now running in Let's Encrypt production, and I've successfully issued a certificate on a subdomain with `issuemail` set to critical.



Patch:
diff --git a/va/caa.go b/va/caa.go
index 40497d12a69..8dc6331a33d 100644
--- a/va/caa.go
+++ b/va/caa.go
@@ -335,6 +335,12 @@ func filterCAA(rrs []*dns.CAA) ([]*dns.CAA, []*dns.CAA, bool) {
 			// do not store the contents of the property tag, but also avoid setting
 			// the criticalUnknown bit if there are critical iodef tags.
 			continue
+		case "issuemail":
+			// We support the issuemail property tag insofar as we recognize it and
+			// therefore do not bail out if someone has a critical issuemail tag. But
+			// of course we do not do any further processing, as we do not issue
+			// S/MIME certificates.
+			continue
 		default:
 			// The critical flag is the bit with significance 128. However, many CAA
 			// record users have misinterpreted the RFC and concluded that the bit


Test patch:
diff --git a/va/caa_test.go b/va/caa_test.go
index 56a38a8181f..758fda4c2b0 100644
--- a/va/caa_test.go
+++ b/va/caa_test.go
@@ -998,6 +998,7 @@ func TestFilterCAA(t *testing.T) {
 				{Tag: "issue", Value: "a"},
 				{Tag: "issuewild", Value: "b"},
 				{Tag: "iodef", Value: "c"},
+				{Tag: "issuemail", Value: "c"},
 			},
 			expectedIssueVals: []string{"a"},
 			expectedWildVals:  []string{"b"},
@@ -1008,6 +1009,7 @@ func TestFilterCAA(t *testing.T) {
 				{Tag: "issue", Value: "a", Flag: 128},
 				{Tag: "issuewild", Value: "b", Flag: 128},
 				{Tag: "iodef", Value: "c", Flag: 128},
+				{Tag: "issuemail", Value: "c", Flag: 128},
 			},
 			expectedIssueVals: []string{"a"},
 			expectedWildVals:  []string{"b"},