Time, it gives everything context especially in Public Key Infrastructure (PKI).

There a few way time comes into play with PKI the most obvious is that internal to a Certificate Authorities own infrastructure they use highly accurate and secure time sources to ensure any statements about time they make are accurate that all systems agree on the time.

Then there is the question of notarization, when a subscriber (a certificate holder) signs something how does a relying party (the person looking at the signature) know it has been signed just now or  a year ago – that’s where time stamping comes in.

These same concepts come into play in financial systems; remember the movie Entrapment? They stole a few seconds of time during a system update and netted millions. OK its just a movie and surely sensationalizes the concept of time but in reality these are real problems – you need trusted time.

Some of you have heard me discuss aspects of us building our new datacenter, one of the first services we are deploying to it is trusted time and time-stamping. The two most common protocols used for time stamping are Authenticode and RFC3161, the protocols are similar in nature, in both a client posts a binary blob to the server which is then time stamped; each protocol uses a different Content-Type in the case of Authenticode it is “application/octet-stream” and for RFC3161 it is “application/timestamp-query”.

If you look at most time stamping services (ours included today) they require to use different URIs (/scripts/timestamp.dll for Authenticode and /tsa for RFC3161 for example) but this just makes things more difficult for the user unnecessarily. To address this in our new service we will be using the posted Content-Type to ensure the right back-end service gets the timestamp request (though our old URLs will continue to work as well).

We use Nginx to do this remapping as it is our edge proxy server in this environment; I thought it might be useful for others to see how one can implement this sort of remapping as I did not see any great examples on the internet, here is what this might look like if you have a similar problem.

server {
listen       80;
server_name  timestamp.example.com;

 

location / {
if ($request_method = GET ) {
rewrite ^ http://www.example.com/timestamping;
}

 

if ($http_content_type = “application/octet-stream”) {
set $args “worker=authenticode”;
}

 

if ($http_content_type = “application/timestamp-query”) {
set $args “worker=rfc3161”;
}

 

proxy_set_header Host $http_host;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_connect_timeout 3s;
proxy_read_timeout 3s;
proxy_pass http://timestamp1/process?$args;
}

}

With this configuration, no matter what URI the timestamp is sent to and whatever protocol it is sent via it will get routed to the appropriate timestamp server.

I should note I excluded a number of items like rate limiting and error handling to keep the post simple, these are also important concepts for you to consider in such a deployment.

Good Luck!