Anais - Engenharia de Redes de Comunicação - UnB

A creator signature, in comparison, seals the document. Since the Authorization
Requirements attribute is signed, the constraints it defines cannot be changed later. This
signature can also be employed with any kind of file. Thus, a single specification and
implementation is required instead of one for each file format.
Nevertheless, the usage of the creator signature also has its drawbacks. One of
the biggest problems with this approach is the overhead in storage and cryptographic
operations it results in. This may not be significant when we consider a single document,
where an extra signature represents just some KBytes more in storage. The size depends
on the inclusion or not of certificates and revocation data within the signature. However, as
we scale, the impact of that signature becomes quite evident. We could take, for example,
the amount of documents that transit everyday in a Court of Justice, or in a big company.
Every extra signature added to the process may represent hundreds of GBytes in storage an
precious processing power. Moreover, an extra signature increases the time spent on the
validation process, thus, bringing inconvenience to its use. A deeper analyses of the costs
in storage an the amount of operations related do digital signatures in conventional X.509
PKIs can be found in the work of da Silva [da Silva 2011] and Moecke [Moecke 2011].
In a general sense, the introduction of the creator signature with authorization
requirements does not obsoletes existing solutions. It only presents a generic solution that
is applicable in a wider range of scenarios.
6. Conclusion
In this paper we described the necessity of a way to specify constraints upon required
signatories regarding identity and authorization and a way to bind these constraints to an
electronic document. Existing solutions to deal with this necessity were evaluated and a
new approach, the creator signature, was proposed.
The creator signature, along with the Authorization Requirements attribute, allows
the author to specify the identity and/or the attributes of the signatories that shall sign a
given document. It then enables generic applications to validate the authorization of those
signatories, based on the author’s requirements. This approach is especially useful in
contexts where a document depends on a specific set of signatures to acquire value, while
the content of that document does not follow any pre-defined format. Examples include
legal proceedings, business contracts and others.
Future work includes the definition of the XAdES version of the Authorization
Requirements attribute and the implementation of a prototype application to test the proposal.
Furthermore we plan to make an adaptation of the proposed model to work with a
Notary Based Public Key Infrastructure (NBPKI)[Moecke 2011]. Thereby we intend to
decrease the overhead of an additional signature discussed in Section 5. Finally, we wold
like to explore the possibility of including authorization delegation schemes in our model.
This would allow signature authorizations to be delegated under specified conditions.
References
Adobe Systems Incorporated (2008). Document management - Portable document format
403