[cabfpub] CA Contact info, etc.

Phillip philliph at comodo.com
Thu Mar 8 19:21:16 UTC 2018


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. badstuff at example.com. 


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:reports at example.com"
_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.





More information about the Public mailing list