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

0 103: SEQUENCE
{
2 38: SEQUENCE {
4 36: SEQUENCE {
6 34: SEQUENCE {
8 3: OBJECT IDENTIFIER role (2 5 4 72)
13 27: SET {
15 25: SEQUENCE {
17 23: [1] {
19 21: [6] ’Director’
: }
: }
: }
: }
: }
: }
42 34: SEQUENCE {
44 32: SEQUENCE {
46 30: SEQUENCE {
48 3: OBJECT IDENTIFIER role (2 5 4 72)
53 23: SET {
55 21: SEQUENCE {
57 19: [1] {
59 17: [6] ’Financial Manager’
: }
: }
: }
: }
: }
: }
78 25: SEQUENCE {
80 23: SEQUENCE {
82 21: SEQUENCE {
84 3: OBJECT IDENTIFIER role (2 5 4 72)
89 14: SET {
91 12: SEQUENCE {
93 10: [1] {
95 8: [6] ’Department Supervisor’
: }
: }
: }
: }
: }
: }
: }
Figure 3. Contract Authorization Requirements ASN.1
this way. That is because natural languages are inherently ambiguous and this turns the
constraint’s interpretation and localization in the text a lot more difficult and imprecise.
On the other hand, the inclusion of signature authorization requirements in the
documents underlying structure is more suitable for automated validation. Once there is
a clear specification of where those requirements shall be included and how they shall
be interpreted, the software implementations become easy. Still, in principle, any kind of
electronic file can be signed. While it is possible to promote the structural changes needed
on some file formats, expanding those changes to all types of files would be impractical.
Obviously, the employment of the signature requirements is more common in electronic
documents and PDF is currently one of the most widely used file formats for documents.
As shown in section 3, PDF already offers internal structures for the inclusion
of constraints upon future signatures. What it does not provide, though, is an integrity
guarantee of those constraints. In a sense, the constraints only work as guidelines, since
they are subject to changes until signatures are applied to the document.
402