### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current Behavior

When attempting to sign some document using Localstack KMS inside a lambda container (also running on localstack), the localstack KMS listener returns some unknown error.

The KMS key and lambda containers have been created from the same CDK app deploy, and I can see all the resources in the localstack web console.

The test application I'm using to prove this behaviour is available here:
https://github.com/LukaHedt/localstack_kms_test

Instructions to run are in the main Readme, and the `/localstack/Readme.md` file.

`aws-sdk` returns an unknown error, and the localstack docker logs that I receive are available here:
https://pastebin.com/58Z3fXi3

Have done an amount of testing and can confidently claim the following:
- Have tested on multiple machines with the same outcome
- Doesn’t make a difference if I specify an ARN or a KeyID in the signing request
- Downgrading localstack versions either didn’t make a difference, or I couldn’t actually deploy a localstack container with version 0.12.20 or lower.

### Expected Behavior

KMS Sign should return a signature for the given payload.

### How are you starting LocalStack?

With a docker-compose file

### Steps To Reproduce

Test application demonstrating the current behaviour is available here:

https://github.com/LukaHedt/localstack_kms_test

Full instructions to run are in the `/localstack/Readme.md` file.


### Environment

```markdown
- OS: MacOS Monteray 12.3
- LocalStack: 0.14.0
```


### Anything else?

_No response_
"""
Response serializers for the different AWS service protocols.
The module contains classes that take a service's response dict, and
given an operation model, serialize the HTTP response according to the
specified output shape.
It can be seen as the counterpart to the ``parse`` module in ``botocore``
(which parses the result of these serializer). It has a lot of
similarities with the ``serialize`` module in ``botocore``, but
serves a different purpose (serializing responses instead of requests).
The different protocols have many similarities. The class hierarchy is
designed such that the serializers share as much logic as possible.
The class hierarchy looks as follows:
::
                                      ┌───────────────────┐
                                      │ResponseSerializer │
                                      └───────────────────┘
                                          ▲    ▲      ▲
                   ┌──────────────────────┘    │      └──────────────────┐
      ┌────────────┴────────────┐ ┌────────────┴─────────────┐ ┌─────────┴────────────┐
      │BaseXMLResponseSerializer│ │BaseRestResponseSerializer│ │JSONResponseSerializer│
      └─────────────────────────┘ └──────────────────────────┘ └──────────────────────┘