Prevent hijacking namespaces

[LourensVeen]

Signing policy rules ensures that only the owner of a namespace can make rules for the assets inside of it. However, there is currently no security check on the ownership of the namespace itself. That is, I can register a site that claims to own a namespace that is already in use by another site, then add rules to my policy server, signed with my private key, that give me permission to access someone else's data.

That's clearly not good. A simple solution is to have the Registry check that the namespace of a to-be-registered site is not already registered by another site. Then namespaces are effectively handed out on a first-come-first-serve basis, and no clashes occur. On the other hand, this can still be problematic if we allow deregistering sites, because copies of a deregistered site may still hang around in the DDM, and then someone could claim the namespace and gain access. Unless we add a grace period like TCP TIME_WAIT or like you have with DNS domains...getting complicated. Also, sites now have to trust the registry to do this, and we want to limit the required trust in the registry as much as possible.

A better solution, and this was always the plan anyway, is to register X.509 certificates for parties instead of bare public keys. These could then contain a Subject Alternative Name with the namespace, which could be a DNS subdomain. Verifying that that domain belongs to the listed organisation can then be done by the CA, which is set up to do that. Even if a site has been deregistered, presumably the organisation still owns the domain, and no one else will be able to register a certificate for that domain. The Registry will then when registering a site check that the name and the namespace match tho O field and the SAN in the certificate, and that the certificate has been signed by a generally trusted CA. With this set-up, the sites can (and should) do their own due diligence though, and verify when checking policy rule signatures that the signature verifies against the certificate public key, and that the namespace of the affected asset matches the SAN. Then you'll at least need a rogue CA to steal people's data, which I think is good enough for now.

Come to think of it, if we list the policy server API endpoint in the certificate as well, and only accept policies for the namespace from that server, then you'll need a DNS spoofing attack as well.