Signed images

what signature algorithm to use, how keys will be distributed, and how signatures will be stored --markwash

for algorithms and signature storage, the DMTF OVF specifies it in detail (SHA1/SHA256 and a cert file which contains the signature of the package manifest). -- edoardo

More information needed:
 1. is this just for the provider (i.e. signature given on import)
 2. is it also for the consumer (i.e. signature provided on GET) (I'm guessing this one)
 3. what signature algorithms to use (looks like DMTF might be a good approach to start from)
 4. what mechanism to use for distributing and validating public key for an image
 5. where to expose the signature in the API images schema

I'd like to take on getting answers to 3 and 4 above myself (markwash)
markwash more-info 2014-03-14

I think it's for both provider and the consumer, as markwash mentioned above. And I prefer SHA256, but I think it can be configured. I think the signature can be exposed by image extra property. So I think the key part need to investigate is verifying that the keypair in question is valid for this particular image. So I will dig into it either. -- flwang

Great proposal to have this integrated into Glance. Some of the related work using additional layers on top of the image store from High Energy Physics using X.509 is at http://grid.desy.de/vm/hepix/vwg/doc/pdf/Book-a4.pdf. This includes the idea of an endorser (individual) and the organisation along with a lifetime. Not sure if this make the implementation more complex but it is worth ensuring these use cases are covered -- Tim

Tim, thanks for the great sharing. It's a nice reference. I will review it and see how to collaborate.
-- flwang

I had a chat on my side with my local super-duper-smart security expert. And he convinced me that public key distribution isn't really a problem we need to worry about if we just adopt some existing technology stack, like say PGP (my preference) for the signatures/certificates. Does using PGP sound like an okay way to go?
Are we also clear that the only use case we're going for here is for the IaaS provider to verify the image on import/upload?
Finally, any thoughts about detached signatures vs just having a new container format that includes the signature?
markwash more-info 2014-04-04

Mark, thanks for the comments. As for your questions, see my comments as below.
1. Does using PGP sound like an okay way to go?
    It's ok for me.
2. Are we also clear that the only use case we're going for here is for the IaaS provider to verify the image on import/upload?
    I would say there are two typical scenarios:
    > client to server: client upload the image, then IaaS provider(Glance server) verify the image.
    > server to client: client or Glance consumer will verify the image if it's created by authorized originator or if it's tampered or not.
3. Any thoughts about detached signatures vs just having a new container format that includes the signature?
    It's a good question. And I would like to raise it in in the design summit session to get some comments about this.
    There is a similar discussion from docker related to this: https://github.com/dotcloud/docker/issues/2700
    * As for new endpoint, it maybe like below (copied from above link)
     GET /v1/images/(image_id)/signatures
     PUT /v1/images/(image_id)/signature
     GET /v1/images/(image_id)/signature/(signature-hash)
     DELETE /v1/images/(image_id)/signature/(signature-hash)
    * As for detached way, I still think we can leverage Barbican.

--flwang 2014-4-29