)]}'
{"specs/newton/approved/api-support-image-signing.rst":[{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"3f595dc0c578ad4865610b32b7bef2ad8e152249","unresolved":false,"context_lines":[{"line_number":111,"context_line":"When signature verification does not occur, the image service client will"},{"line_number":112,"context_line":"return an empty list as the certificate chain. This empty list will be added"},{"line_number":113,"context_line":"to the Instance as the \"signing_certificate_chain\" and returned by the API in"},{"line_number":114,"context_line":"response to a show request."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Alternatives"},{"line_number":117,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_e4c8a9aa","line":114,"updated":"2016-05-31 16:23:41.000000000","message":"I have a really hard time believing that providing a report of the certificate chain via the API is a good approach. It is essentially punting the problem of identifying validation to the client user or app, and experience of web browsers shows they\u0027ll likely just ignore it, or not understand it, or get validation wrong, or all of the above.\n\nThis approach of reporting certs for the instance and having the user verify them means that there is no way to actually prevent the VM being booted from an image with invalid certs. You have to boot the image, then query the cert chain, then verify it, and then kill the instance if the verification failed. I think that\u0027s really awful - for this to be credible, we should be able to prevent us getting anywhere near booting the instance. We should have a system that lets us immediately stop the boot request the moment we\u0027ve checked the image cert chain.","commit_id":"b35bf37a7c52d96ab7e3236b916381dd233a8b8f"},{"author":{"_account_id":6783,"name":"Nathan Reller","email":"nathan.s.reller@gmail.com","username":"rellerreller"},"change_message_id":"73f05eb8ce3b040dede24a38d4193aa8f45c25e6","unresolved":false,"context_lines":[{"line_number":111,"context_line":"When signature verification does not occur, the image service client will"},{"line_number":112,"context_line":"return an empty list as the certificate chain. This empty list will be added"},{"line_number":113,"context_line":"to the Instance as the \"signing_certificate_chain\" and returned by the API in"},{"line_number":114,"context_line":"response to a show request."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Alternatives"},{"line_number":117,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_1268f4b9","line":114,"in_reply_to":"9abb7d3a_1545a216","updated":"2016-06-03 00:05:59.000000000","message":"\u003e if we want to see where a VM\u0027s disk image came from, we can simply ask glance about that image\n\nOne of the primary reasons for this feature is to not trust Glance. The signature is there to protect against Glance modifying it. Therefore we cannot ask Glance about the image.\n\nI see the benefit in that security people can view the certificate of what was booted. We can identify anomalous or malicious behavior. I think this is beneficial in public clouds where a user wants to verify the integrity of the image.\n\n\u003e Just providing the signing certificate does not allow us to protect against the case where the same user has uploaded multiple images signed with the same cert\n\nGood point. You are correct about having to provide the signature. We would need that because we not only need to verify the certificate but the hash as well. The downside about providing the signature is securing them. I don\u0027t know how to do that off-hand. I wish we had signed the hash of the image. Then the user could provide the certificate and the hash. The hashes could be stored in public and signed with an organization\u0027s private key along with the image name or something. I guess you could do the same with a signature blob it just seems a little less user friendly, and it is not as portable. I\u0027m thinking out loud with this, but we do need a good answer for how to secure the signature.","commit_id":"b35bf37a7c52d96ab7e3236b916381dd233a8b8f"},{"author":{"_account_id":6802,"name":"Joel Coffman","email":"jmc7tp@gmail.com","username":"joel-coffman"},"change_message_id":"edf1e24ba902dbdc1ce2f9216598e0db9675f56a","unresolved":false,"context_lines":[{"line_number":111,"context_line":"When signature verification does not occur, the image service client will"},{"line_number":112,"context_line":"return an empty list as the certificate chain. This empty list will be added"},{"line_number":113,"context_line":"to the Instance as the \"signing_certificate_chain\" and returned by the API in"},{"line_number":114,"context_line":"response to a show request."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Alternatives"},{"line_number":117,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_bd7afdba","line":114,"in_reply_to":"9abb7d3a_1be547db","updated":"2016-06-01 14:44:17.000000000","message":"Certificate validation (not part of this work) will stop the boot immediately if the certificate chain is invalid. Certificate validation limits the use of self-signed certificates and eliminates the possibility that an attacker uses a CA that\u0027s known to be compromised to sign their certificate.\n\nThis specification addresses a concern noted on a different specification (https://review.openstack.org/#/c/188874/19):\n\n  [..] consider two users with authorized access to glance Fred and Bob\n  - Fred uploads image XXX with signature AAA\n  - Bob uploads image YYY with signature BBB\n  - Fred tells Nova to boot image XXX\n  - Glance gives Nova back image YYY and signature BBB\n  - Nova verifies signature BBB against image YYY and succeeds.\n  As a result Fred is *not* running the image which they originally\n  uploaded - they are instead running an image from Bob.\n\nIn this case, the signature is valid but the user has no way to detect that a different image has been booted. One possibility to address this issue is to allow the user to specify the signature (\"AAA\" in the example above) as part of the boot request. That approach has the drawback of not being transparent to the user -- i.e., the signature must be provided. Another possibility is to allow the user to check the signature after the fact, which is the approach described here. This approach has the advantage of being transparent to the user and allows the user to do additional checking only if they\u0027re inclined to do so.","commit_id":"b35bf37a7c52d96ab7e3236b916381dd233a8b8f"},{"author":{"_account_id":15524,"name":"dane-fichter","email":"dane.fichter@jhuapl.edu","username":"dane-fichter"},"change_message_id":"93f154b27ea6f27bb8ca9e181faec479f6a51805","unresolved":false,"context_lines":[{"line_number":111,"context_line":"When signature verification does not occur, the image service client will"},{"line_number":112,"context_line":"return an empty list as the certificate chain. This empty list will be added"},{"line_number":113,"context_line":"to the Instance as the \"signing_certificate_chain\" and returned by the API in"},{"line_number":114,"context_line":"response to a show request."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Alternatives"},{"line_number":117,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_3e7bd929","line":114,"in_reply_to":"9abb7d3a_1be547db","updated":"2016-05-31 17:11:23.000000000","message":"Perhaps the use cases could use some clarification. The first use case refers to an image which has been signed by a certificate which is trusted by some CA which the deployment trusts, but the end user may not trust that CA. The second use case is in the same vein. Can you cite examples of major browsers moving away from displaying this data? I just checked the latest versions of Chrome, Safari, and Firefox, and they all display this information simply by clicking the padlock icon.\n\nOn a less pedantic level, one goal of the image signature validation feature as a whole is that it should be as transparent as possible to the end user The end user should be able to easily check that their image\u0027s signature was verified, that the signing cert is familiar to them (either theirs or another entity that they trust), and that there\u0027s cryptographic assurance that the signing certificate is trustworthy. I\u0027m open to alternate suggestions for how to do this, but to me this change seems like the most straightforward way to prove to the end user that they should trust the integrity of the disk image they\u0027re using.","commit_id":"b35bf37a7c52d96ab7e3236b916381dd233a8b8f"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"b26286de0056d2069eb88d994f64b195b2dde8bf","unresolved":false,"context_lines":[{"line_number":111,"context_line":"When signature verification does not occur, the image service client will"},{"line_number":112,"context_line":"return an empty list as the certificate chain. This empty list will be added"},{"line_number":113,"context_line":"to the Instance as the \"signing_certificate_chain\" and returned by the API in"},{"line_number":114,"context_line":"response to a show request."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Alternatives"},{"line_number":117,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_f2614f06","line":114,"in_reply_to":"9abb7d3a_3e7bd929","updated":"2016-06-01 15:18:28.000000000","message":"I wasn\u0027t actually referring to the padlock icon directly. Rather the gradual change in the way the UI deals with cases where the certificate fails validation. Historically browsers would display details of the failure to the user and ask them whether to continue or abort. These days, firefox will just display a warning saying the connection is insecure and not provide any way to continue to view it, by default. You have to open up advanced info, and manually add an exception before it\u0027ll let you continue. This is part of a general trend away from presenting security information to users \u0026 asking them to make decisions on it, and encouraging them to just accept the decisions made by the browser.\n\nSince we\u0027re building from a clean-slate here, I really think we should strive for a similar situation where the user provides initial input (valid certs/sigs) and then lets nova make the decision, and *not* build a system where the user is expected to view \u0026 analyse certificate chains.","commit_id":"b35bf37a7c52d96ab7e3236b916381dd233a8b8f"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"923d98182e15976fd58e30ac242e16fce59aa06e","unresolved":false,"context_lines":[{"line_number":111,"context_line":"When signature verification does not occur, the image service client will"},{"line_number":112,"context_line":"return an empty list as the certificate chain. This empty list will be added"},{"line_number":113,"context_line":"to the Instance as the \"signing_certificate_chain\" and returned by the API in"},{"line_number":114,"context_line":"response to a show request."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Alternatives"},{"line_number":117,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_1545a216","line":114,"in_reply_to":"9abb7d3a_8ed525e6","updated":"2016-06-02 13:27:55.000000000","message":"\u003e I think this is a good goal, but we need to be prepared for cases where we don\u0027t catch it. \n\n[snip]  my replies to this spec have mostly been focusing on dealing with the case of a malicious glance which provides incorrect information back to nova. I believe what I describe copes with that attack scenario fine.\n\nYour examples here outline a different attack scenario not mentioned in the use cases of this spec. In the case you describe, you have an attacker signing bogus images and then uploading them to glance. In this scenario glance itself is not compromised and working fine. As such, if we want to see where a VM\u0027s disk image came from, we can simply ask glance about that image - I\u0027m not seeing the need for nova to expose the certificate validation chain to trace that.\n\nIf we want to expand the use cases section in this spec to cover other types of attack that is fine of course. We just need to be clear about what attacks we\u0027re aiming to protect against and validate the design against those stated problems\n\n\u003e I agree that the chain is useless for most users. I don\u0027t think it hurts to have this additional information.\n\nEvery new feature we add has a direct cost for ongoing maint of nova codebase, as well as consuming time from reviewers which is already in demand. As such we definitely avoid adding features just because we can - we want to see clear compelling user need for features we add - \"it doesn\u0027t hurt\" is not justification enough.\n\n\u003e The downside about this approach is where will you keep the signature?\n\nWRT providing the signature at time of boot, the user whom uploaded the image originally will have the signature they originally provided to glance, and so would be able to \nprovide it to nova again when booting. Alternatively organization may have a list of their trusted signatures maintained in a secure location outside the cloud that they use when booting trusted instances\n\n\u003e I\u0027m trying to think if providing the signing certificate would be enough. \n\nJust providing the signing certificate does not allow us to protect against the case where the same user has uploaded multiple images signed with the same cert. eg user may upload a RHEL-7.2 disk image initially, then a security alert comes out, so they upload a newer version of that image. THey want assurance that Nova is actually booting the updated image and that glance hasn\u0027t substituted the old vulnerable image. Since you can\u0027t trust glance to provide the signature itself and the signing cert can\u0027t be used to distinguish the images, the only option is to provide the signature to nova directly.","commit_id":"b35bf37a7c52d96ab7e3236b916381dd233a8b8f"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"b26286de0056d2069eb88d994f64b195b2dde8bf","unresolved":false,"context_lines":[{"line_number":111,"context_line":"When signature verification does not occur, the image service client will"},{"line_number":112,"context_line":"return an empty list as the certificate chain. This empty list will be added"},{"line_number":113,"context_line":"to the Instance as the \"signing_certificate_chain\" and returned by the API in"},{"line_number":114,"context_line":"response to a show request."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Alternatives"},{"line_number":117,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_d5f7d5d0","line":114,"in_reply_to":"9abb7d3a_bd7afdba","updated":"2016-06-01 15:18:28.000000000","message":"@Joel wrt to the situation you describe - it would be sufficient for Nova to report the signature of the image that it booted to the user. There is no need for the user to see the full certificate chain to detect the case where glance gave back image YYY + sig BBB, instead of image XXX + sig AAA.\n\nI would be fine with seeing an API extension to report just the signature associated with the image, as that\u0027s merely a moderately short hex string that can be verified by simple comparison against what they originally provided to glance. It doesn\u0027t require the user to interpret any x509 certificate data to validate it.\n\nDespite this I think it is critical that we can be able to provide a signature with the boot request, so that it is always possible for the user to avoid ever booting the malicious image. That should be the number 1 goal IMHO. Verification after booting is always the worse option.\n\nThe problem where glance returns Bob\u0027s image to Fred\u0027s request can also be mitigated against by allowing users to have their own signing certs, and associating certs with users in openstack. eg Fred should be able to say he only wants nova to boot images signed by Fred\u0027s cert, and not by Bob\u0027s cert.","commit_id":"b35bf37a7c52d96ab7e3236b916381dd233a8b8f"},{"author":{"_account_id":6783,"name":"Nathan Reller","email":"nathan.s.reller@gmail.com","username":"rellerreller"},"change_message_id":"39a364d2da6b1fb387e255f4bbd5ad2b22a54194","unresolved":false,"context_lines":[{"line_number":111,"context_line":"When signature verification does not occur, the image service client will"},{"line_number":112,"context_line":"return an empty list as the certificate chain. This empty list will be added"},{"line_number":113,"context_line":"to the Instance as the \"signing_certificate_chain\" and returned by the API in"},{"line_number":114,"context_line":"response to a show request."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Alternatives"},{"line_number":117,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_8ed525e6","line":114,"in_reply_to":"9abb7d3a_d5f7d5d0","updated":"2016-06-02 00:40:22.000000000","message":"@Daniel \n\n\u003e it is always possible for the user to avoid ever booting the malicious image.\n\nI think this is a good goal, but we need to be prepared for cases where we don\u0027t catch it. We could have an adversary who has a trusted certificate, and we don\u0027t know that his signed images are bad yet. This information would be nice for an ongoing investigation. If this information is available to be queried then we may be able to notice patterns about who is signing malicious images.\n\nConsider a bunch VMs that get compromised. We could look at who provided them and this may provide more information.\n\nI also like this feature from a personal point of view as well. I like to look at certificate chains. I know I\u0027m not normal for this, and I agree that the chain is useless for most users. I don\u0027t think it hurts to have this additional information.\n\n\u003e I think it is critical that we can be able to provide a signature with the boot request\n\nThe downside about this approach is where will you keep the signature? What would prevent an attacker from modifying that as well? Users can\u0027t always recreate the signature because not all users will have the private key. Plus I would need access to known pristine image, and the time would painful.\n\nI\u0027m trying to think if providing the signing certificate would be enough. What do you think about that? Could we provide just that? Essentially this would say that the signing certificate must be this exact certificate. Then the rest of the validation proceeds as normal if and only if they are identical. I think that would work instead of providing the actual signature. Certificate repositories are already out there and in public, so getting that would be much easier than signature. Thinking out loud here, so I hope this makes sense.","commit_id":"b35bf37a7c52d96ab7e3236b916381dd233a8b8f"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"628f09447d98ec0e227a348e5f550e0d76e2dc3c","unresolved":false,"context_lines":[{"line_number":111,"context_line":"When signature verification does not occur, the image service client will"},{"line_number":112,"context_line":"return an empty list as the certificate chain. This empty list will be added"},{"line_number":113,"context_line":"to the Instance as the \"signing_certificate_chain\" and returned by the API in"},{"line_number":114,"context_line":"response to a show request."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Alternatives"},{"line_number":117,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_1be547db","line":114,"in_reply_to":"9abb7d3a_df0d6ce9","updated":"2016-05-31 16:52:31.000000000","message":"Your \"use cases\" description here is talking about this is if it were the only mechanism for detecting problems. eg you say \n\n\"The end user wants to create an instance from a signed image, and be able to\ndetect any of the following attacks:\n\n* An adversary replaces the desired image with another signed image\n\n* An adversary alters the desired image and the signature metadata\"\n\nAssuming you implemented the other mechanism whereby nova validates the image against a known good trust store, then the use cases listed in this spec are basically already solved. So this really makes one question what the benefit of this spec really is.\n\nIt seems like the only remaining point is to allow Horizon to present a bit of UI that lists the cert chain. I\u0027m not seeing that as being very compelling, because the overwhelming majority of users won\u0027t understand this, nor the implications of what it means. This is rather why browsers have been moving away from showing this kind of data to users, and just unconditionally blocking access to websites that fail validation.","commit_id":"b35bf37a7c52d96ab7e3236b916381dd233a8b8f"},{"author":{"_account_id":15524,"name":"dane-fichter","email":"dane.fichter@jhuapl.edu","username":"dane-fichter"},"change_message_id":"d8033f43edebc09dd4f8119d55bfbfe1d6f4e209","unresolved":false,"context_lines":[{"line_number":111,"context_line":"When signature verification does not occur, the image service client will"},{"line_number":112,"context_line":"return an empty list as the certificate chain. This empty list will be added"},{"line_number":113,"context_line":"to the Instance as the \"signing_certificate_chain\" and returned by the API in"},{"line_number":114,"context_line":"response to a show request."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Alternatives"},{"line_number":117,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_df0d6ce9","line":114,"in_reply_to":"9abb7d3a_e4c8a9aa","updated":"2016-05-31 16:38:56.000000000","message":"This is not intended to be the only means of certificate validation. We intend to publish a change this development cycle which incorporates certificate validation in the signature verification process. This will validate that the certificate which was used to sign the image was signed by a trusted root or intermediate certificate. If this validation fails, the instance will not boot. During the certificate validation phase, the certificate chain which is referenced here is built and added to the instance object so that it can be reported to the end user.","commit_id":"b35bf37a7c52d96ab7e3236b916381dd233a8b8f"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"3f595dc0c578ad4865610b32b7bef2ad8e152249","unresolved":false,"context_lines":[{"line_number":122,"context_line":"certificate has been validated against a trusted CA. The deployment may trust"},{"line_number":123,"context_line":"a larger set of root CAs than an end user trusts, so merely verifying an"},{"line_number":124,"context_line":"image\u0027s signature and validating the signing certificate may be insufficient"},{"line_number":125,"context_line":"to meet the end user\u0027s requirements."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Data model impact"},{"line_number":128,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_04ce8d81","line":125,"range":{"start_line":125,"start_character":35,"end_line":125,"end_character":36},"updated":"2016-05-31 16:23:41.000000000","message":"Rather than Nova reporting the certificate chain and have the client user/app check that to see if they trust the chain, I think we should reverse it.\n\nHave the user provide details of certificates that they trust, and then Nova can validate that the trust path of the image only includes certs in the user provided whitelist. This whitelist of trusted certs could be associated with a tenant user identity, or be provided at the time the VM boot API call is made.\n\nThis has the benefit that we don\u0027t need to expose any details of the cert chain when reporting about an instance, nova just handles that internally. It also means that nova can avoid even starting the instance if the chain is invalid.","commit_id":"b35bf37a7c52d96ab7e3236b916381dd233a8b8f"},{"author":{"_account_id":15524,"name":"dane-fichter","email":"dane.fichter@jhuapl.edu","username":"dane-fichter"},"change_message_id":"d8033f43edebc09dd4f8119d55bfbfe1d6f4e209","unresolved":false,"context_lines":[{"line_number":122,"context_line":"certificate has been validated against a trusted CA. The deployment may trust"},{"line_number":123,"context_line":"a larger set of root CAs than an end user trusts, so merely verifying an"},{"line_number":124,"context_line":"image\u0027s signature and validating the signing certificate may be insufficient"},{"line_number":125,"context_line":"to meet the end user\u0027s requirements."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Data model impact"},{"line_number":128,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_ffd030f8","line":125,"range":{"start_line":125,"start_character":35,"end_line":125,"end_character":36},"in_reply_to":"9abb7d3a_04ce8d81","updated":"2016-05-31 16:38:56.000000000","message":"Again, the end user visually inspecting the chain is not the only validation mechanism. We will allow Nova operators to configure a trust store. When Nova boots a signed image, the certificate used to sign this image will be validated against a certificate in this trust store. Again, the instance will not be booted if this validation fails.","commit_id":"b35bf37a7c52d96ab7e3236b916381dd233a8b8f"},{"author":{"_account_id":15524,"name":"dane-fichter","email":"dane.fichter@jhuapl.edu","username":"dane-fichter"},"change_message_id":"d8033f43edebc09dd4f8119d55bfbfe1d6f4e209","unresolved":false,"context_lines":[{"line_number":324,"context_line":"Dependencies"},{"line_number":325,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":326,"context_line":""},{"line_number":327,"context_line":"* Implementation of certificate validation functionality [2], [3]"},{"line_number":328,"context_line":""},{"line_number":329,"context_line":""},{"line_number":330,"context_line":"Testing"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_5fe4dcaa","line":327,"updated":"2016-05-31 16:38:56.000000000","message":"@Daniel Berrange: The certificate validation functionality is introduced in the original image-signing Nova spec and described again in the cross-project spec. We fully intend to implement a programmatic means by which Nova will validate the signing certificate\u0027s chain. This API change is only meant as means by which this data will be made visible to the end user.","commit_id":"b35bf37a7c52d96ab7e3236b916381dd233a8b8f"},{"author":{"_account_id":2750,"name":"Sean Dague","email":"sean@dague.net","username":"sdague"},"change_message_id":"3e28fedd24945b6028b6c0f54450d816fa3ecf0c","unresolved":false,"context_lines":[{"line_number":215,"context_line":"  Ngo/dMoqqpXdi2/0BYEcJ8pjsngrFm+fM2BnyGpXH7aWuKsWjVFGlWlF+yi8I35Q"},{"line_number":216,"context_line":"  8wFJt2Z/XGA7WWDjvw++"},{"line_number":217,"context_line":"  -----END CERTIFICATE-----\""},{"line_number":218,"context_line":"            }"},{"line_number":219,"context_line":"        ],"},{"line_number":220,"context_line":"        \"key_name\": null,"},{"line_number":221,"context_line":"        \"links\": ["}],"source_content_type":"text/x-rst","patch_set":2,"id":"9abb7d3a_f002ac71","line":218,"updated":"2016-06-02 13:50:59.000000000","message":"This content is going to be *so* infrequently used. If we are adding it to the API I\u0027d honestly rather put it on a dedicated sub resource, because it is going to be unused most of the time.\n\nGET /servers/{id}/image_signature","commit_id":"07ac48dd736a8db050dbf9b533c8ef79aeb530c2"}],"specs/ocata/approved/api-support-image-signing.rst":[{"author":{"_account_id":7012,"name":"Brianna Poulos","email":"Brianna.Poulos@jhuapl.edu","username":"brianna-poulos"},"change_message_id":"c103022923ac7639f07079024421cabe72eb32cd","unresolved":false,"context_lines":[{"line_number":107,"context_line":"trust in addition to the image data whenever image signature verification"},{"line_number":108,"context_line":"occurs. The proposed change adds the certificate chain to the Instance object"},{"line_number":109,"context_line":"as a list variable with the name \"signing_certificate_chain\". The Nova API"},{"line_number":110,"context_line":"populates the response to the show request with this certificate chain. The"},{"line_number":111,"context_line":"\"signing_certificate_chain\" field is a list of structures, each of which"},{"line_number":112,"context_line":"contains the distinguished name, the public key algorithm and size, and the"},{"line_number":113,"context_line":"base64 encoding of a certificate in the chain. RFC 5280 specifies the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bacf61ea_d8054b46","line":110,"range":{"start_line":110,"start_character":23,"end_line":110,"end_character":42},"updated":"2016-08-01 16:07:45.000000000","message":"Should this be \"to the image signature request\" instead?","commit_id":"bcc51689ad2e5216e1a67136d3eb94a731dbcd86"}]}