We'll skip the political bashing and go straight to the facts. Murphy says, what can go wrong will go wrong and that's the situation we are in now.

The following document describes a way to ensure privacy and identity on the web. This approach is fully compliant with existing RFCs and IETF standards and has the nice side effect that it would render void passwords on the web.

The question remains, is the ordinary user able to handle such a high tech approach or would he get lost?

The current concept of HTTP and HTTPS requests and responses is leveraged to deliver signed and optionally encrypted requests and responses. Nesting encrypted requests or responses in unencrypted requests or responses ensures that the present software and hardware infrastructure of the Internet will operate normally.

The key technique to achieve signing and encryption of requests and responses is request and response nesting. An unencrypted request may deliver an encrypted request, which may carry a signed request, which carries the actual request. If encryption is not desired, the outer unencrypted request would be the signed request, which carries the actual request.

Request nesting is slightly more complicated than response nesting. In order to deliver a payload from a requester to the responder, a POST request with some additional header fields and a request body must be sent. This is different from ordinary HTTP GET requests that do not contain a request body. The payload of such an HTTP POST request is the actual request, such as a GET, HEAD, PUT (etc) or another POST request. Response nesting is very straightforward, just like with requests, the response header response header will contain additional header fields and the response body will contain the actual response.

This specification defines several context relevant HTTP header fields. For example, the signature of requests and responses is delivered in HTTP header fields. The entire list of new HTTP header fields is given below.

The nature of PGP requires that the entire message is available before en/decryption or signature validation can start. This requires that both client and server have the necessary resources to handle these requests, for example enough memory to process larger requests or enough computational power to handle several requests in parallel.

A new mime type is introduced. The new mime type “encryption/PGP” indicates the fully PGP encrypted part of a message. Several new HTTP header fields manage the control and communication flow between the two counterparties.

The following sections describe all new header fields and their purpose.

PGP-Sig

The header field “PGP-Sig” must contain the signature of the enclosed request or response body. The signature must be BASE64 encoded. As the signature might be a relatively long string, it may span multiple lines as defined in RFC 2616, section 4.2.

The signature algorithm must be specified in the tag “PGP-Sig-Algo”.

PGP-Sig-Algo

The header field “PGP-Sig-Algo” contains the name of the algorithm used for calculating the signature. Typical values are “SHA1” and “MD5”.

PGP-ID

The header field “PGP-ID” must contain the PGP identity, by which the entity is known to the communication partner. Typically, the communication partner will use the value of this header field to look up a public key in a private or public key directory.

PGP-Enc-Required

The header field “PGP-Enc-Required” specifies that the communication partner MUST encrypt all requests and responses.

PGP-Sig-Required

The header field “PGP-Sig-Required” specifies that the communication partner MUST sign all and include the signature in requests and responses.

PGP-ID-Probe

The header field “PGP-ID-Probe” signals that the communication SHOULD respond with his identity or return an HTTP error code if this is not possible, for example due to configuration or technical reasons.

PGP-Public-Key

The header field “PGP-Public Key” MUST contain the public PGP key of an individual in BASE64 encoding. As the key might be a long string, the key string may span multiple lines as defined in RFC 2616, section 4.2. . Implementations may process this field.

PGP-PK-Request

The header field “PGP-PK-Request” signals that the communication partner SHOULD include his public key in the next request or the next response. The communication partner may choose to return an error.

For signalling errors, such as signature verification, decryption or encryption errors, the already established HTTP error signalling mechanisms are used. At the moment, this document does not define which HTTP response code must be used for which error, but at least throwing a 500 response with additional text is encouraged.

The communication partners nest HTTP requests and responses in signed or encrypted envelopes. If a request or a response is encrypted and if the request or response includes the signing of data, the communication partner MUST include the signature in an encrypted envelope. If requests or responses are both signed and encrypted, the signature must not be sent outside the encryption envelope.

Encrypted requests or responses MUST not be wrapped in a signed request, but the opposite is allowed.

Signed requests contain the PGP signature of the actual request an entity wants to send. The actual request is sent as a form-data part of a POST request.

The following examples exemplifies the nesting of the actual HTTP request in a POST request that contains the PGP signature.

POST / HTTP/1.1
Host: my.personal.bank.com
PGP-ID: [email protected]
PGP-Sig: a2b31231232adbcfe2231...
 a8293bcd23fa382...
PGP-Sig-Algo: SHA1
Content-length: 15

GET / HTTP/1.1

The following request exemplifies the nesting of a signed HTTP request in an encrypted HTTP request.

POST / HTTP1.1
Host: my.personal.bank.com
Content-Type: encryption/PGP  
Content-Length: 510  

a9bc212d334 [etc.]

When decrypted, the encrypted part would be the signed request shown above.

Responses work similar to requests. The responder may sign the actual response body and must then put the signature into the response header. The responder may wrap a signed response into an encrypted response but must not wrap an encrypted response into a signed response.