Name Delegation Design Discussion

[philips]

DNS delegation is the idea that I can own the domain example.com but delegate hosting of my container images to container.hosting. Think MX records, where I have a DNS name that tells me where to send email for a domain without the dedicated special DNS record.

Today, AppC supports a method for doing this type of delegation that uses HTTPS, and HTML meta tags. This type of delegation is inspired by the method used by the go get package management system as well.

One critique of this method is that there is an RFC for this sort of meta information called 'well-known URIs'. I believe that using this type of well-known scheme is a better choice today and will stay out of people's way better; in fact we prototyped this in a project called abd.

FAQ Why not DNS: If we used DNS it would make it hard to bootstrap trust of this source based on the existing well understood TLS infrastructure on the internet today. With systems like Let's Encrypt in place today I think it would be smart to rely on this existing trust root. We do this in rkt today and it works nicely.

But I have this way better way of doing delegation: We can add additional methods, but having some method to start for delegation is super helpful.

I don't want to allow outbound traffic to the internet: Container engines can allow for this feature to be turned off or configure that certain domains are statically delegated to internal mirrors. This is all about having a default UX.

[wking]

On Wed, Apr 06, 2016 at 05:15:43PM -0700, Brandon Philips wrote:

I believe that using this type of well-known scheme is a better choice today and will stay out of people's way better…

I think blob delegation should be outside the scope of the image format, since blobs that are content-addressed based on a cryptographic hash can be fetched from any content-addressable storage (CAS)—although registries probably want to include hints about hosts providing blobs required by a given image 1. Baking CAS repository information into the image manifests requires folks to make distribution-time decisions at image-creation time (and image authors and distributors need not be the same people).

 Subject: DNS-based delegation (was: Proposal for a new project: OCI Image Format Spec)
 Date: Sat, 12 Mar 2016 15:34:11 -0800
 Message-ID: <20160312233411.GB10073@odin.tremily.us>

[philips]

@wking This isn't about blob delegation. This is about delegation of naming for images. Which is explicitly in scope (see the README).

[wking]

On Thu, Apr 07, 2016 at 06:47:35AM -0700, Brandon Philips wrote:

@wking This isn't about blob delegation. This is about delegation of naming for images. Which is explicitly in scope (see the README).

Ah, it's just about discovering manifest hashes. Developing and versioning the separate image/naming/signing components 1 in a single repository sounds complicated to me (do you make a major bump when you adjust the naming spec, even though you haven't touched the image spec?). But discovering manifest hashes using an approach like this sounds like one of several reasonable registry approaches to me.

[stevvooe]

@philips Let's make a note here to consider cases such as notary for naming delegation.

Have we decomposed naming delegation to particular set operations?

[philips]

@stevvooe I don't see how notary relates to name delegation. Do you have a doc?

[philips]

@stevvooe Ping.

[stevvooe]

@philips You can read here. The link is fairly straightforward. Let me know if you have more questions.

Perhaps, I am misunderstanding naming delegation. We may need a clear definition and identification specific use cases it solves for the individual user. Part of the crux with naming delegation is that it is great for ISVs and service providers but I'd like to better understand where the user gains benefit. We struggled with our efforts from this angle when we looked into this. If I were, say, a data scientist, why should I have to setup DNS and a web service to deploy software in my local infrastructure?

I do find such strategies as go get or well-known urls to be elegant but getting them reliably deployed can be a nightmare in some organizations (well-known being the clear winner here, perhaps).

We also may want to value offline use cases slightly higher. In typical deployments, there may only be a few organizational mirrors. In the abd examples and some of the proposals we had in this area, it focuses on mirrors in the Internet at large but it seems more likely to have a local mirror, rather than spreading requests across the internet.

[ibuildthecloud]

Every enterprise I work with wants a trusted repository of data. This is a model they are very familiar with. Think rpm/deb repo or Java's maven repos. How does this name delegation model work for this model? For example imagine nginx comes from nginx.com. But in the "enterprise" they want to mirror the images from nginx.com to their local servers such that when a user pulls "nginx" it goes to the on prem repo and not the internet.

[philips]

Configuration to declare where the mirror is for nginx.com or more likely '*'. It is just namespaces that has some default useful semantics.

On Thu, Apr 21, 2016, 7:49 PM Darren Shepherd notifications@github.com wrote:

Every enterprise I work with wants a trusted repository of data. This is a model they are very familiar with. Think rpm/deb repo or Java's maven repos. How does this name delegation model work for this model? For example imagine nginx comes from nginx.com. But in the "enterprise" they want to mirror the images from nginx.com to their local servers such that when a user pulls "nginx" it goes to the on prem repo and not the internet.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/opencontainers/image-spec/issues/11#issuecomment-213218303

[ibuildthecloud]

Does this work today already on rkt or appc? I'd like to understand more. I'm trying to wrap my head around this. The fact that it's model after go is the problem for me. Go has so many distribution problems where other languages like node and Java don't really. But the fundamental difference in the two is that node/Java have a centralized de facto store for everything (npm/mvn central). I have an easier time grasping the idea that name resolution is not decentralized but instead done based on a small set of chosen trusted sources.

[timthelion]

@ibuildthecloud Is what you are suggesting actually, technically different than an indefinitely caching proxy with a hand written white list? In that case, such proxys already exist, and no software on OPCs side is necessary. Just set up your "in enterprise" systems to use the companies proxy, and curration and trust management can happen when writting the white list.

[kamalmarhubi]

Is there room for TUF's delegation notions to get incorporated here? The have a pretty fine grained way of delegating trust for certain packages to different sources, with a well-studied set of security / authenticity guarantees.

[wking]

On Fri, Apr 22, 2016 at 09:08:29AM -0700, Kamal Marhubi wrote:

Is there room for TUF's delegation notions to get incorporated here?

Notary [1,2] is a wrapper around TUF. More notes on that and thoughts about trust delegation here 3.

 Subject: Signature verification after image-format translation
 Date: Fri, 15 Apr 2016 14:50:18 -0700
 Message-ID: <20160415215018.GR23066@odin.tremily.us>

[philips]

On Fri, Apr 22, 2016 at 9:08 AM Kamal Marhubi notifications@github.com wrote:

Is there room for TUF http://theupdateframework.com/'s delegation notions to get incorporated here? The have a pretty fine grained way of delegating trust for certain packages to different sources, with a well-studied set of security / authenticity guarantees.

Namespaces in TUF and in particular Notary can use a DNS form.

Here is a concrete example from the docs: https://github.com/docker/notary/blob/master/docs/getting_started.md#understand-notary-naming

[brendandburns]

Here are the three use cases as I see it:

1) User doesn't care at all about name delegation, they use an existing registry for all images (e.g. gcr.io/brendanburns/foo, gcr.io/brendanburns/bar, ...)

2) User is running inside their own data center, doesn't trust anyone, doesn't want to go outside their LAN. In this case user still doesn't care about delegation, but they run their own registry and push all images their: (e.g. my-registry.internal/foo, my-registry.internal/bar)

Neither of those two care about name delegation.

3) The interesting middle use case is when someone wants to establish domain based policy (e.g. 'you can only run images from my-company.com) but doesn't want to run their own registry. In that context, they want their end-users to pull my-company.com/bar/foo but have that image actually be hosted on my-company.com.gcr.io/bar/foo

it seems to me that there are two questions here:

1) How do you securely get/set the mapping from my-company.com to my-company.com.gcr.io?

Options here appear to be DNS CNAME records, or a well-known URI.

Pros for CNAME are:

• Natural fit for lots of other examples
• No serving system requirements (can use one of N different cloud DNS providers)

Cons for CNAME:

• requires taking over an entire domain, can't use (my-company.com require registry.my-company.com)
• Harder for clients to write code (DNS libraries are immature compared to HTTP)
• Security requires DNSSEC which isn't fully implemented (or at all) by some providers.

Pros for well known URI:

• Easy to poke at (curl ...)
• Security uses well known HTTPS certs, etc.

Cons for well known URI:

• Extra complexity: have to run a server (though you probably already do)
• More opaque, less elegant approach.

2) Can you manipulate the rest of the image path? If so how?

I think the answer here should be "no" the risks are just to big and the win is minimal.

[stevvooe]

@brendandburns To clarify, are you saying that the user should be able to configure the naming authority for my-company.com? If a user pulls, my-company.com/bar/foo and gets my-company.com.gcr.io/bar/foo, what is the name of the resulting image?

2) Can you manipulate the rest of the image path? If so how?

I think the answer here should be "no" the risks are just to big and the win is minimal.

We can agree, here. Allowing remotes or local to manipulate paths quickly gets out of hand.

Put differently, if we expressed naming as a function f(name) -> y, what is the type of y? Can we express the naming problem in this manner?

[brendandburns]

@stevvooe the name of the image is still my-company.com/bar/foo just like if you visit www.company.com and it CNAME's to storage.googleapis.com your browser still shows www.my-company.com in the URL bar.

[brendandburns]

@stevvooe put another way, this all happens in the DNS subsystem, so the client code pulling the image doesn't even notice. They just see my-company.com resolve to 1.2.3.4 which happens to be the IP for my-company.com.gcr.io

[philips]

On Wed, Apr 27, 2016 at 3:27 PM Brendan Burns notifications@github.com wrote:

The interesting middle use case is when someone wants to establish domain based policy (e.g. 'you can only run images from my-company.com) but doesn't want to run their own registry. In that context, they want their end-users to pull my-company.com/bar/foo but have that image actually be hosted on my-company.com.gcr.io/bar/foo

Yes, exactly.

it seems to me that there are two questions here:

1) How do you securely get/set the mapping from my-company.com to gcr.io?

Options here appear to be DNS CNAME records, or a well-known URI

CNAME doesn't work if you want TLS delegation to be "secure", right?

I think of delegation based on DNS/well-known URI as a "globally distributed default". If you want to override the default you need to configure that policy at a cluster/machine level, similar to download credentials.

Depending on the language we come up with here it will look like something like this:

"delegationOverrides": [
 {
    "name": "example.com/*",
    "mirrors": ["gcr.io"]
 },
 {
    "name": "quay.io/*",
    "mirrors": ["gcr.io"]
  }
]

2) Can you manipulate the rest of the image path? If so how?

I think the answer here should be "no" the risks are just to big and the win is minimal.

+1 the entire name should be sent to the delegating party.

[brendandburns]

It seems to me that TLS should be fine, as long as the thing you are delegating to holds the cert for the original registry.

I think there are two cases to consider (and maybe this is the source of confusion) there is the pure delegation case: "I don't have a registry, but I want a vanity domain" and the mirror case "There's some registry out there, but for various reasons, I want to actually access those images at some other mirror location".

I was really mostly thinking about the former. The mirror one is sort of interesting but doesn't seem like a server-side protocol, but rather a client-specific configuration.

[stevvooe]

It seems to me that TLS should be fine, as long as the thing you are delegating to holds the cert for the original registry.

I don't see how we can dismiss TLS here. We still need to provide secure connections to both the white label domain and the upstream. They may be different.

How can this happen at a pure dns-level if the primary and delegate domains may have different implementations and certificates? If it really is just pure DNS, why not just tell users to use a CNAME and be done with this? If it really is just CNAMEs, do we even need to specify anything?

[brendandburns]

@stevvooe I'm not dismissing TLS. The CNAME option would involve a user defining a whole subdomain (e.g. registry.mycompany.com) creating a new different cert just for that subdomain, and storing that cert with their registry provider. And then CNAME over to the registries DNS, (similar to the flow here: https://www.keycdn.com/blog/cdn-ssl-made-easy/)

I think the goal in the spec is to design the best practice for how it would work, so that implementors know what they need to build (e.g. an interface that accepts a cert), even if the actual mechanism doesn't require an implementation.

Anyway, CNAME is one of the two options. A well-known URI is the other option. I tried to list the pros and cons of each in my earlier post

I think that the best effort in this issue is to decide which option is preferred by the maintainers.

If it is easier for me to put the options and pros/cons into a markdown doc and have the discussion in a PR, I can do that too. (and if I missed any pros/cons let me know)

[stevvooe]

@brendandburns I see. Sorry about the harsh wording here.

How is this different from using TLS with a CNAME as one normally would? It sounds like a very standard usage. Am I missing something? Why does it need to specified? Seems like it belongs in recommendations or best practices.

As an interesting data point, I have suggested this approach situations looking "spruce" up the registry urls. Typically, this is easy if you host your own registry. The problem arises when using providers such as AWS ECR, Docker Registry and GCR (please correct me if I am wrong). They would have to host a private key for each domain. Would such a provision push a requirement for services running a registry to accept certificates to use for white labeling?

[brendandburns]

@stevvooe In my mind, hosting keys isn't really a challenge for most cloud providers, since they already have to do it in order to terminate SSL for their load balancers.

Regarding spec. versus best practice, I guess the point is that this issue says: "define a spec" if we decide that CNAME is what we would suggest then we'll just close this issue as "done" ;)

[stevvooe]

In my mind, hosting keys isn't really a challenge for most cloud providers, since they already have to do it in order to terminate SSL for their load balancers.

In principal, but are any registry providers currently offering this? I couldn't find it in gcr or ecr and I don't think Docker Hub has it either.

Either way, I am not sure that CNAME is an interesting case. It sounds like more interesting topic is decoupling naming from location.

[ibuildthecloud]

Is there some technical reason why this discussion is termed "name delegation" and not "discovery?" It seems so much simpler if we talk about discovery. That is just defining a process of looking at X, Y, and Z in some specific manner.

[timthelion]

In my understanding, name delegation and discovery are two related processes, and one is harder than the other ;). Name delegation is the science of creating unique identifiers, it typically requires either centralization or randomness. In the DNS system, name delegation is centralized, when you create a new domain name, you reserve it in a central registrar. However, DNS lookup (aka discovery) is de-centralized, you typically use the DNS server provided to you by your ISP, and indeed, there is no way to even access the central registry for most devices.

I think that both problems are interesting, though I feal name delegation is FAR FAR FAR more vital in terms of "lets not f--- this up", as it is much harder to change and fix after the standard is published.

On 04/29/16 04:19, Darren Shepherd wrote:

Is there some technical reason why this discussion is termed "name delegation" and not "discovery?" It seems so much simpler if we talk about discovery. That is just defining a process of looking at X, Y, and Z in some specific manner.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/opencontainers/image-spec/issues/11#issuecomment-215612525

[brendandburns]

@stevvooe CNAME is one way of decoupling naming from location. It's a way of saying: "for this location, the canonical (that's the 'C') location is this other location over there"

and though no one currently provides it, it seems that the point of developing a specification is to encourage providers to add support.

Again, in my mind there are two options with the pros and cons outlined above. Though personally I prefer the CNAME solution, it seems like the purpose of this issue is to get to a "(dis)agree and commit"

I'm not sure what the process is for that. Shall we just have a vote?

[philips]

@brendandburns Yes, the purpose is to get to a solution and commit. Ping the other maintainers: @jonboulle @jstarks @jbouzane @vbatts to chime in on how they feel. If you are coming new to this thread see @brendandburns excellent write-up on pros/cons of various options for name delegation.

Also, paging @josephschorr from the Quay.io team as well as we have considered this feature for quite some time (we called it "white label").

Personally, I am leaning towards well-known as it gives a "zero trust" sort of model to delegation. It is also is used by other "modern" internet plumbing stuff like OpenID Connect.

[josephschorr]

@brendandburns, @stevvooe: Speaking just from the perspective of the registry, as @philips alluded to, we've considered the idea of "white labeling" via CNAME for some time. The original goal was to allow name owners (e.g. "redhat.com") to delegate pulls from their own domain to Quay, such that docker pull cooldomain.com/someimage would be rewritten as docker pull quay.io/someorgforcooldomain/someimage. We quickly realized that there were two major issues with doing so:

1. It wouldn't really work for the top-level domains when used for the internet as a whole, which means that a subdomain would have to be used (e.g. "docker.cooldomain.com")
2. We'd have to store private keys as all our traffic is SSL terminated.

The SSL issue in particular is the reason we did not move forward, as storing private keys on behalf of a variety of users is a concerning proposition. Well-known has the nice benefits of working with top-level domains and not requiring us to store keys, so we'd prefer that route from our perspective. It also has the nice added bonus of allowing domain owners to choose dynamically to serve different images from different registries.

[stevvooe]

@philips I still think we need a solid problem definition before moving forward. I'd still like a solid answer to, if we represent naming delegation as a function f(name) -> y, what is the type of y? The reason I ask it in this format is that for well-known vs CNAME, the type of y may be very different. In the well-known case, y could be a fairly wide set of protocols and locations. With CNAME, the type of y is just another address and the client is left to resolve the target protocol.

This brings other questions. Is f configurable? Can name be transformed before passing to f?

[wking]

On Fri, Apr 29, 2016 at 12:08:51PM -0700, Stephen Day wrote:

… if we represent naming delegation as a function f(name) -> y, what is the type of y?

Labels to all the steps would be nice. In the beginning, you have something like ‘cooldomain.com/someimage’. In the end you have a CAS hash from which you can unpack the bundle (see also #23). It sounds like things folks have discussed are:

• metadata_interpolate(name, platform_information) -> URL 1
• cname_redirect(URL) → URL 2
• well_known_redirect(URL) → URL 3
• local_mirror(name?) → URL? 4

At what point does this turn into CAS requests for pulling the actual image? And if those CAS requests are over HTTP, where are they sent?

[brendandburns]

@stevvooe @philips

I think the problem definition is

func getNamespaceDelegate(originalName DomainName) (DomainName, error)

where an IP address is a degenerate domain name.

I see no reason not to do anything else.

There may be a bigger type (e.g. []Mirror) used to implement that function, but that's what the function is.

[wking]

On Mon, May 02, 2016 at 09:40:16AM -0700, Brendan Burns wrote:

func getNamespaceDelegate(originalName DomainName) (DomainName, error)

If your initial image name is ‘cooldomain.com/someimage’, I'm guessing ‘cooldomain.com’ is what you're feeding this function. Are you requiring DNS- or IP-based names for all images and not supporting names like ‘debian’? Or are those names allowed, and they just don't get namespace delegation? And how is the resulting DomainName tied back into CAS resolution?

[brendandburns]

Personally, I think we need to require well-formed domain names.

Both of the methods discussed so far (either DNS or a well-known-URI) require a domain name that is resolvable.

[wking]

On Mon, May 02, 2016 at 09:49:26AM -0700, Brendan Burns wrote:

Both of the methods discussed so far (either DNS or a well-known-URI) require a domain name that is resolvable.

For DNS-based delegation, sure, but DNS-based naming and delegation is optional 1. The overall name-resolution problem is to go from a container name (whatever format) to a CAS hash. In [2,3] I sketch out name → CAS hash in a generic:

registryLookup(name, trustStore) → (CAS hash, error)

format, and having more clarity on how this optional DNS-delegation layer fits into that bigger picture would be helpful.

 Subject: Re: [oci-tob] Proposal for a new project: OCI Image Format Spec
 Date: Tue, 1 Mar 2016 14:00:06 -0800
 Message-ID: <20160301220006.GH4265@odin.tremily.us>

 Subject: Re: [oci-tob] Proposal for a new project: OCI Image Format Spec
 Date: Tue, 1 Mar 2016 21:29:47 -0800
 Message-ID: <20160302052947.GL4265@odin.tremily.us>

[brendandburns]

I guess my view on this is that they are two related, but independent problems.

In my mind, here is how they go together:

Basically registryLookup(...) in your above requires the name of an actual, functioning registry.

Whereas getNamespaceDelegate just requires a registry name (which may be an alias)

So the code looks like this:

var originalName DomainName

resolvedName := originalName
for {
  newName, _ := getNamespaceDelegate(resolvedName)
  if newName == resolveName {
    break
  }
  resolvedName = newName
}
hash, _ := registryLookup(resolvedName, trustStore)

[wking]

On Mon, May 02, 2016 at 10:12:42AM -0700, Brendan Burns wrote:

Basically registryLookup(...) in your above requires the name of an actual, functioning registry.

I was imagining users could configure their client to use a number of registries, over a number of registry protocols. Then the client could check them all (“Registry1, have you heard of image ‘debian’? No? Registry2, have you heard of image ‘debian’? Ah you have three images called ‘debian’. It looks like I only trust the second and third, and the third is newer, so off to the CAS engine to resolve sha256:ca6e…”).

But yeah, clients would have to have registry configuration transmitted out-of-band.

“So the code looks like this…”

Ok, so this is optional pre-processing for image names that look like domains. That sounds good to me, and explains why the delegation functions are domain/IP → domain/IP mappings.

[brendandburns]

hrm, I kind of strongly believe that all images are the combination of the (registry, image-name) tuple. e.g. an image named debian shouldn't exist, there is an image named debian.org/debian

For the purposes of trust, this means that either:

Owner delegated trust (aka, registry aliases) I trust debian.org and debian.org delegates trust to gcr.io via either of the mechanisms described above.

or

User delegated trust (aka corporate mirrors) I explicitly configure the client to say "I trust debian.mycorpmirror.org for debian.org or alternately, I trust mycorpmirror.org for *

[wking]

On Mon, May 02, 2016 at 10:59:16AM -0700, Brendan Burns wrote:

hrm, I kind of strongly believe that all images are the combination of the (registry, image-name) tuple…

I disagree, but this level of trust discussion should probably happen in #22. For the purpose of DNS-based delegation, we agree that you need an initial domain name associated with the image to seed the delegation algorithm.

[stevvooe]

@brendandburns The problem with assuming that an image is an (registry, image-name)-tuple is that we couple naming to the registry, we couple trust to the registry. The ideal setup for this is to ensure that degian.org/debian is the same where ever it comes from, given the same configuration on a client. If trust is delegated to gcr.io, an image named gcr.io/debian.org/debian shouldn't pop up somewhere. Only debian.org/debian should exist.

But this is part of my concern for including naming and transport in an image specification: once we start talking about any of these, we must start talking about trust. While I understand the reasoning in including these, it feels like including TLS in the HTML specification.

[stevvooe]

@brendandburns BTW, thank you for the functional description. This can help to ensure we are discussing the same approach.

Abstractly, we can say the function looks like this:

func resolve(name string) (Location, error)

Where Location can be either an alias or concrete location.

[brendandburns]

Personally, I think its important that name is a resolvable domain name, so I'd rather have some type other than string in there, but other than that, yes, that seems correct.

[brendandburns]

@stevvooe I guess I just fundamentally disagree. the domain name in the image name isn't a registry, its a namespace. We may ultimately resolve the domain name, and try to find a registry, but calling it a registry in this context confuses what we are trying to achive.

I shouldn't even go looking for debian.org/debian anywhere unless either:

a) debian.org delegates trust to some other registry b) I (or my admin) have explicitly configured a mirror in my client config.

I don't think that we want random registries around the world serving images that they grabbed from other locations without those locations explicit consent.

[stevvooe]

@brendandburns I'm not sure how you can disagree with your own assertion:

hrm, I kind of strongly believe that all images are the combination of the (registry, image-name) tuple.

Based on what you've said, I'm also confused as to how you can disagree with the following:

The problem with assuming that an image is an (registry, image-name)-tuple is that we couple naming to the registry, we couple trust to the registry. The ideal setup for this is to ensure that degian.org/debian is the same where ever it comes from, given the same configuration on a client. If trust is delegated to gcr.io, an image named gcr.io/debian.org/debian shouldn't pop up somewhere. Only debian.org/debian should exist.

Why should debian.org be responsible for debian.org's trust? Shouldn't it be up to the client to decide who to trust if they want to trust debian.org? Why should "trust" be delegated to the registry?

[brendandburns]

@stevvooe I'm in favor of both (hence the a) and b) in the previous comment) but I believe that the default should be that the trust is placed in the domain name.

For better or worse, domain names are the entities that hold the root of trust in our world. By default, if I see an image that is google.com/foo I'm going to assume that Google is responsible for that image, and therefore it seems to me that the google.com domain name should be responsible for the trust (or the delegation of the trust), since Google/google.com is on the hook for the reputation of the image.

Users should be able to override who they trust (that's the part b) in the above) but it should definitely be an explicit, client side action for example, I could imagine a "mirror config" for a client that looks like:

{
   "mirrors": [{
         "host": "google.com",
         "registry": "gcr.io"
    }, 
   ...
}

which explicitly says that the client should map google.com to gcr.io in the resolution step above.

Importantly, I expect this kind of configuration to be the exception not the rule.

[wking]

On Mon, May 02, 2016 at 01:25:19PM -0700, Brendan Burns wrote:

For better or worse, domain names are the entities that hold the root of trust in our world.

The X.509 hierarchy based on some assumed-responsible CAs is fine, and a reasonable choice for a number of workflows. But I don't see a need to require it in the spec. For example, if I know the publisher (say, because I work with them) and I trust their OpenPGP key, I don't see why I wouldn't trust name↔hash assertions signed by that key. There's no reason why an OCI verification framework couldn't support both OpenPGP and X.509 signatures, so why force the latter?

[brendandburns]

Hrm, I really think we're conflating two issues:

1) is who do I trust for name to hash resolutions, and in that context, I 100% agree that if I trust a registries keys, its fine for me to trust their name to hash regardless of whether then name matches their domain name or not.

2) how do resolve a (possibly aliased) image name down to a concrete image name.

This issue is concerned with 2.

I don't think we want to make name resolution be part of what a registry does, I think we want to do all of the name resolution first, and then go to one or more registries for the name to hash mapping using the fully resolved image name.

[wking]

On Mon, May 02, 2016 at 01:35:29PM -0700, Brendan Burns wrote:

2) how do resolve a (possibly aliased) image name down to a concrete image name.

This issue is concerned with 2.

Both of those issues should be covered by the trust model. Otherwise a malicious agent could abuse the image-name canonicalization to point folks at the “wrong” canonical name.

[stevvooe]

then go to one or more registries for the name to hash mapping using the fully resolved image name.

This still delegates the trust model to the registry.

The problem comes when working with multiple registries. Which keys do you trust when they disagree? The only way to manage this is centralization. One approach is to partition the namespace with DNS.

I am not sure that one can honestly separate naming and trust models without redundancy and ambiguity. Can this be done without making such separate systems completely incompatible?