LID GPG Credential

From LID Wiki

An HTTP GET or POST request carrying a credential of this credential type must be signed using GNU Privacy Guard's "clearsign" command.

The following algorithm is applied:

1. Start with the base URL of the request (e.g. http://example.com/foo)
2. Append all URL arguments that are part of the request URL, properly escaped (e.g. bar=baz and argl=brgl, leading to http://example.com/foo?bar=baz&argl=brgl)
3. If this is a POST request and additional arguments are conveyed through the HTTP content, append all such arguments as-if they were part of the URL. For example, if the HTTP content contained lid-message-type=mime:text/plain, lid-message=Hi%20Mom. and lid-credtype=gpg%20--clearsign, this would lead to http://example.com/foo?bar=baz&lid-nonce=20050911030123Z&lid-message-type=mime:text/plain&lid-message=Hi%20Mom.&lid-credtype=gpg%20--clearsign
4. Sign the entire URL (although it is never sent that way), using gpg --clearsign, and append the "compacted signature" (see below) at the end with the lid-credential keyword. In case of an HTTP POST, appending on the end means "as the last parameter in the HTTP content; in case of all other HTTP verbs, appending at the end means "as the last argument to the URL".

In this example, the resulting request to host example.com would be as follows:

POST /foo?bar=baz&lid-nonce=20050911030123Z http/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 1234
 
lid-message-type=mime:text/plain&lid-message=Hi%20Mom.&lid-credtype=gpg%20--clearsign&lid-credential=SHA1%0AVersion%3A%20GnuPG%20v1.4.0%20(GNU%2FLinux)%0A%0AiD8DBQFCCDkcNmrPV%2Bm2dK4RApnCAJ93%2BYermhVf9hDOWA1DJSByVpvWLwCfdwdq%0AffEWUmo9irjN7EI19Muu%2Bm8%3D%0A%3DnIxG

Note that for the purpose of signing, it is entirely irrelevant which parameters are provided as part of the URL, and which are provided as part of the HTTP POST payload, as long as the sequence remains the same. Of course, all parameters must be provided as part of the URL for HTTP GET requests.

"Compacted signature"

GPG produces a signed document that looks as follows:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
http://example.com/foo?bar=baz&lid-nonce=20050911030123Z&lid-message-type=mime:text/plain&lid-message=Hi%20Mom.&lid-credtype=gpg%20--clearsign
-----BEGIN PGP SIGNATURE-----
 
Version: GnuPG v1.4.0 (GNU/Linux)
 
iD8DBQFCCvzNNmrPV+m2dK4RArX1AKCHuoocAMl7q98dymOd4rdO2NlaEQCbBp6f
UAnlIpEtc8suusCabMkgsvo=
=pKrG
 
-----END PGP SIGNATURE-----

For use in LID, the signature component is compacted into the following:

SHA1%0AVersion%3A%20GnuPG%20v1.4.0%20(GNU%2FLinux)%0A%0AiD8DBQFCCDkcNmrPV%2Bm2dK4RApnCAJ93%2BYermhVf9hDOWA1DJSByVpvWLwCfdwdq%0AffEWUmo9irjN7EI19Muu%2Bm8%3D%0A%3DnIxG

according to the following algorithm:

• Take the string following the keyword Hash: , in this case SHA1.
• Append an ASCII newline character (\n).
• Append everything from Version: to (but not including) the carriage return before line -----END PGP SIGNATURE-----.
• Of course, this string must be escaped properly before it can become part of a URL.

When reconstructing the entire GPG signature on the receiving end, these steps must be reversed.