Establish publisher authority via automated DNS backed challenges?

[woodruffw (William Woodruff)]

@ncoghlan

a protocol for clients and repositories to use to confirm that a domain-authority API entry in a Python package repository JSON response is valid (such queries would be sent to the domain authority URL, NOT to the repository server). Both HTTPS and DNS seem like plausible candidates here, but HTTPS would probably be simpler (and avoid various categories of attack that would otherwise arise due to these values being static metadata rather than the dynamic challenge tokens used in ACME).

I’d definitely strongly recommend having this be HTTPS only, and not reusing DNS-01 or HTTP-01 or other pre-secure-origin challenge mechanisms! Those mechanisms are great for Let’s Encrypt’s purposes, but the package index is in the fortunate position of being higher up on the stack; given that a secure origin (= HTTPS) should probably be table stakes for domain verification anyways, my suggestion would be to use the .well-known URI scheme (RFC 8615) and have a basic proof served from there.

---

To take a step back, this is indeed separate from Trusted Publishing, but it does dovetail closely with related efforts. TUF has already been mentioned, but it’s also pretty close to the PEP 740 attestation model (which currently assumes Trusted Publishing identities, but was designed to be extended to arbitrary identities, like emails and domains).