DSS and REST

[Andreas Kuehne <kuehne@trustable.de>]

Hi all,

I would like to reconsider my statement to defer the topic 'REST Binding'. I came across a similar problem while designing an interface for the creation of a timestamp-like object. I saw some advantages of this approach and noticed a big enthusiams for REST at my colleagues ;-)
 

A short summarize of the problem:

The REST paradigm is build around the idea of an addressable resource, like the home page of OASIS, the temperature in London Heathrow at 4 a.m., my order #12345 at amazon. You can address it and you retrieve its content with the GET method. Advantage of HTTP's implicit caching mechanism can be taken.

In contrast the creation of a signature for a given document cannot be addressed directly. After successful creation the signature may be addressable (e.g. by adding an additional suffix to the documents URL). But the service of signature creation itself doesn't publish this URL. Moreover, the signing service will usually return a completely different signature every time it will be used. Maybe it selects from a pool of signing keys, maybe it includes the signing time, maybe recent OCSP data are included in the signature...

Signing

So the 'processor' pattern (implicit to the common web service) matches the signing process perfecfectly. Adapting the 'processor' pattern to REST ends up with a generic endpoint where a data blob gets posted and another blob is returned. Caching is disabled by the use of POST. This way of using REST smells a bit like the common REST anti pattern 'POST tunnel'. Nevertheless it's the way to go. The REST signing request would be a POST to a URL ending e.g. in .../rest/signatureProducer . In fact this is exactly what's already described as the 'HTTP POST Transport Binding' of the DSS core. So there is no additional work required to do RESTful signing and timestamping.

Verification

More advantage of REST could be taken when looking at the verification request. The result of the verification usually doesn't change over time. And if it really does (e.g. due to a certificate revocation) it could be handy to have access to the result _before_ the revocation did happen. Additionally the verification could be a costly process. So it would be even nicer to take advantage of HTTP's caching.
A possible way to design a RESTful verification call is to define a verification 'resource' by using a hash of the relevant data. The URL may look like .../rest/validity/sha-256/a1b2c3d4...

The first call to this URL will be a GET with no transfer of any additional data necessary. If the requested validity resource is available, the information will be returned immediately in the form the client requested it.. The XML format defined in the DSS spec is the obvious format, but there could also be a readable PDF available or the 'en vogue' JSON could be returned. This will be handy as a compact format for Ajax clients.
In case the server returns a HTTP code of '404' the validity resource is not known yet. Now it's up to the client to create the resource using a PUT call with all the data described in the DSS core for a verification request. From now on the validity resource will be available for any subsequent calls.

A new binding profile 

This verification behavior goes beyond the mechanism described in DSS core. So a new binding document would be required. Moreover it needs a definition of how to build the mentioned resource id. For some type of signatures a simple hash of the referred document seems to be sufficient, but in many cases the things turn out to be more complex. My proposal would be the derive the resource id from the hash of the VerificationRequest object applicable for the specific call. This approach will serve all verification scenarios supported by DSS.

Another interesting topic of the HTTP protocol is the implicit support for asynchronous requests. This would include the async profile into any REST binding implicitly.

Conclusion

A REST binding for DSS affects the verification part only, but it can lead to big improvements in terms of performance especially for mass-verification use cases ( e.g. code signature verification). The profile will not interfere with the current version of the DSS core, no existing implementation may break. Special care needs to be taken for verification calls that modify the signature itself (like XAdES). These profiles should consider supporting the REST binding in detail.
Additionally the popularity of the REST paradigm should be taken into account, especially in the browser based environments. So I would recommend to invest some time into this topic!

Greetings

Andreas