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

3. Authorization Constraints
Paper documents have authorization constraints regarding the signatories specified directly
in the document’s text. This is done by specifying signatories’ names or roles
directly under the signature field. In a similar way, these constraints can also be included
in the contents of an electronic document. Unfortunately, this poses a big challenge to
automated validation of the authorization constraints. We further discuss this challenge
in Section 5.
Another approach consists of including signature authorization requirements in
the document’s underlying structure. For this to be possible, the document’s format definition
must contain clear specifications of the fields in which those requirements shall
be included. They must also specify the syntax and interpretation characteristics of the
requirements. However, different organizations may have control over the definition of
different document formats. This implies that the way document formats specify signature
authorization requirements may differ dramatically from one another.
The Portable Document Format (PDF), defined in ISO 32000-1
[Adobe Systems Incorporated 2008], is an example of a document format that already
provides a specification for signature authorization requirements. This consists of
an internal structure called seed value dictionary. As described in clause 12.7.4.5 of ISO
32000-1, the seed value dictionary’s entries “provide constraining information that shall
be used at the time the signature is applied.”
One of the possible entries in a seed value dictionary that is relevant for authorization
purposes is the Cert entry. This entry contains a certificate seed value dictionary,
which, in turn, contains information regarding certificates that shall be used when signing.
Table 235 of ISO 32000-1 lists all possible entries in a certificate seed value dictionary.
These entries provide numerous ways of filtering acceptable signing certificates. Due to
the goals of this paper, we only refer to the descriptions of the Subject and SubjectDN
entries.
Subject: “An array of byte strings containing DER-encoded X.509v3 certificates
that are acceptable for signing.”[Adobe Systems Incorporated 2008]. This entry, then,
enables the document’s author to specify unequivocally the identities of the acceptable
signatories based on their PKCs.
SubjectDN: “An array of dictionaries, each specifying a Subject Distinguished
Name (DN) that shall be present within the certificate for it to be acceptable for
signing. The certificate ultimately used for the digital signature shall contain all
the attributes specified in each of the dictionaries in this array. (PDF keys and
values are mapped to certificate attributes and values.) The certificate is not constrained
to use only attribute entries from these dictionaries but may contain additional
attributes”[Adobe Systems Incorporated 2008]. This entry is effectively more flexible
than the Subject entry. It still allows constrains over the signatory’s identity, for example
by specifying the expected value of the common name field in the certificate’s Subject DN.
But it also brings the possibility of constraining acceptable signing certificates by other
attributes. These attributes may refer, for example, to authorization credentials, such as
roles or group memberships. In other words, it is possible to constrain acceptable signing
certificates just by specifying attributes that shall be present in these PKCs.
399