# On the Need for a General REST-Security Framework
## 5 Related Work Analysis
### [PERSON] et al.  
[PERSON] et al. [56] introduce the first approach addressing the protection of HTTP responses by proposing a REST-ful HTTP message authentication protocol, which protects the request as well as the response. Their approach introduces new headers containing the certificate ID, the hash algorithm and the signature algorithm name. The input to the signature algorithm is a concatenation of the body, the URL, the hash algorithm name, the signature algorithm name, the certificate ID and a set of headers forming a string to be signed. The generated hash and signature values are stored in separated, newly defined headers each. Moreover, [PERSON] et al. propose an encryption and decryption scheme for HTTP messages.  
One drawback of [56] is the missing reference implementation. This paper provides two pseudo code notations of the signature generation and verification schemes as well as another two of the encryption and decryption schemes. These algorithms do not clearly state whether a timestamp or the HTTP method are considered in the processing. Moreover, they do not specify any order of the concatenation or some form of policy, which retains the order. Likewise, the approach does not define what headers need to be obligatory protected. That is, it is not clear whether all headers or a subset of them must be signed /encrypted.  
### [PERSON] et al.  
[PERSON] et al. [57; 58] define a method for signing and encrypting HTTP messages. The key pairs for performing the encryption, decryption and digital signatures are generated by a third party entity.  
Before a client and a server are starting to communicate with each other, both parties must request two public points (p1, p2), representing the master public key, and a private point (sQ) from a private key generator (PKG). The PKG is the trusted third party service. Its only task is to send the master public key and the private point.  
Based on this master public key and the other endpoint's URL, the client and the server can compute the public key of their communication partner. The private point sQ is then used by both parties to calculate their own private key respectively. Once the key pairs and the public key of the counterpart is present, the client and the server can use the communication partner's public key to encrypt the HTTP message. Before starting the data transfer, the encrypted message is signed by the private key of the corresponding endpoint.  
The approach of [PERSON] at al. ensures the authenticity, integrity and confidentiality of the whole HTTP message. Moreover, requests as well as responses are protected by this scheme. However, the encryption of the whole message with the aim that only the endpoints are able to decrypt and interpret, violates the self-descriptive constraint of REST messages [1]. That is, only the client and the server can understand the intention of the message. Intermediate systems are not able to process the fully encrypted and signed message, as they possess neither the corresponding private key of the client nor the server. If an intermediary is not able to understand and process a traversing message, it may reject forwarding the message or cancel the communication. Hence, ensuring the confidentiality of REST messages requires to cope with special challenges in order to be in conformance with the REST principles. Requirements for defining a confidentiality scheme in REST are discussed in Section 6.3. Another shortcoming of this approach is a missing time variant parameter in the signature process, which makes the scheme vulnerable to replay attacks.