So at the exact minute this topic started, I received a request to review this document:
https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-17 It is essentially the same problem in a slightly different domain. This is targeted at ISPs managing mail servers. But any technology involving certs is likely to end up being referred to CAs. So if anything is done to automate these processes, it should probably try to re-use as much as possible. My proposal is as follows 1. Human friendly identifiers The CPS should specify an abuse contact address, e.g. [email protected]. 2. Machine interpreted identifiers To automate, we want as much consistency as possible. CAA uses domain names to identify CAs. The reason we chose that approach rather than policy OIDs or X.500 DNs is that we can hang anything we want that is machine readable off that domain. Thus if the CA, i.e. the subject of a WebTrust or equivalent audit is example.com Customer grants issue authorization (exists today): example.net. IN CAA 0 issue "example.com" To get the CPS etc. _repository.example.com. SRV 443 100 1 "repo.example.com" CPS directory at https://repo.example.com/.well-known/cabforum/cps/ Contact list at https://repo.example.com/.well-known/cabforum/contacts Etc. [These are just for example] To get the ACME server _acme._tcp.example.com SRV 443 100 1 "host1.example.com" _acme._tcp.example.com SRV 443 100 1 "host2.example.com" Abuse report _cert-pkixrpt.example.com. IN TXT \ "v=TLSRPTv1;rua=mailto:[email protected]"; _cert-pkixrpt.example.com. IN TXT \ "v=TLSRPTv1; \ rua=https://reporting.example.com/v1/wev"; Note that in the above I have deliberately chosen host names that are not www.example.com because you might want to run these off a different host, this is not required. The CA domain identifier could be specified in the end entity cert or an intermediate. Depending on the nature of an intermediate, it may or may not be desirable for it to have a separate domain identifier for these purposes. _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
