Electronic Documents with Signature Constraints

Transcription

1 Electronic Documents with Signature Constraints Felipe C. Werlang 1, Ricardo F. Custódio 1, Roberto Araújo 2 1 Departamento de Informática e Estatística Universidade Federal de Santa Catarina (UFSC) Caixa Postal Florianópolis SC Brazil 2 Faculdade de Computação Universidade Federal do Pará (UFPA) Rua Augusto Corrêa, 01 - Setor Básico Belém PA Brazil felipewer@inf.ufsc.br, custodio@inf.ufsc.br, rsa@ufpa.br Abstract. X.509 Public Key Certificates and Attribute Certificates are well established technologies. They are employed in digital signatures to prove a signatory s identity and authorization. However, there is no standard definition for the way electronic documents should specify the identity and the authorization of required signatories, nor the number of expected signatures. In this paper we propose to bind identity and authorization requirements to a document through a creator signature. For this, we introduce a new signed signature attribute. Keywords: Digital Signature, Authorization, Attribute Certificates, Signature Constraints, Electronic Documents, Authorization Requirements 1. Introduction Modern digital signature standards employ Public Key Certificates (PKCs) to identify the signatories. They also support the inclusion of Attribute Certificates (ACs) in signatures to provide authorization credentials. However, these certificates only certify who signed a given document and what his attributes were. This does not mean that the signatory had the authorization to sign that document. We could take, for example, a court injunction. Although anyone could sign a document containing a court injunction, it only acquires legal value if signed by a judge. This means that applications enforcing authorization constraints in digital signatures have to look for a predefined set of attributes in the signatory s AC. That attribute set, in turn, depends directly on the business process in which the signature is used. Thus, each application ends up tied to a specific business process. Applications designed to incorporate digital signatures in specific business processes, with fixed authorization constraints, are quite common. Examples include management systems and communication protocols. Many kinds of forms also tend to have fixed authorization constraints. However, there are even more cases of documents with dynamic content and format. Each of these documents may have different authorization constraints for its signatures. A good example of this is a business contract. Furthermore, there may be situations where a document has a mix of authorization and identity constraints. For example, a contract between a company and an individual may require the signature of the company s director and the signature of the individual. In this case the first signature has an authorization constraint defined by a role, i.e. Company Director, and the second signature has an identity constraint defined by the individual s identity.

2 From all those possibilities, one realizes that it should be possible to let the author specify which signatures are required for the electronic document he creates. The process would then become similar to the way it is done with paper documents. This would allow applications performing digital signature validation to gather identity and authorization requirements directly from the document. Those requirements would then be enforced against the PKCs and ACs present in the signatures. In order to address this necessity, we propose to bind identity and authorization requirements to a document through a creator signature. For this, we introduce a new signed signature attribute. The structure of the paper is as follows. In Section 2 we briefly describe Attribute Certificates and the support offered by digital signature standards CAdES and XAdES to the inclusion of these certificates. Section 3 describes different alternatives for the inclusion of authorization constraints in a document. Section 4 proposes the concept of a creator signature and introduces a new signed signature attribute. Section 5 discusses advantages and limitations of the proposed solution in comparison to the existing alternatives. Section 6 concludes the paper and describes future work. 2. Attribute Certificates and Digital Signature Standards The digital signature standards CAdES[ETSI 2011] and XAdES[ETSI 2010] currently support the use of X.509 Attribute Certificates [Farrell et al. 2010] to carry the signatories authorization credentials within the signature. X.509 Attribute Certificates(ACs) are certificates that can provide authorization information about a given entity. They are issued by an Authorization Authority(AA) and they reference a single Public Key Certificate(PKC) [Cooper et al. 2008]. These certificates are widely used in access control schemes. A well know example is the Permis Project[Chadwick and Otenko 2002]. The CAdES and XAdES digital signature standards are respectively evolutions of the Cryptographic Message Syntax(CMS) [Housley 2009] and XML Signature Syntax and Processing(XMLDSIG)[Eastlake et al. 2002] formats. They define the attributes that can be present in a digital signature and how those attributes shall be interpreted. Those attributes are classified as signed or unsigned attributes. Signed attributes are included in the signature container before the actual signature value is calculated, therefore becoming part of the signed content along with the document s content itself. Thus, these attributes cannot be altered after the signature is completed. An example of a signed attribute is the Signing Certificate attribute, which holds a reference of the signatory s PKC. Unsigned attributes, in the other hand, are included in the signature container after the signature value calculation. These attributes can be altered at any time. They are used mainly to carry validation data, as certificates and certificate revocation data, and artifacts to extend the lifetime os the signature, such as timestamps. ACs can be included in a CAdES signature with a signed attribute called signer- Attributes. The equivalent in XAdES is the signed property signerroles.

3 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 [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 of ISO , 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 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.

4 4. A Digital Signature with Authorization Requirements In this section we describe the notion of a creator signature. This is a signature performed exclusively by the document s author. We do this by presenting a new signed signature attribute called Authorization Requirements. This attribute is used to specify identity and authorization requirements in a creator signature. A creator signature is technically a normal CAdES or XAdES digital signature. This signature is applied to an electronic document by its author. The author s goal for the signature is to seal the document and bind it to a set of requirements regarding future signatures applied by other parties. Those parties, however, are not going to sign the actual document. Instead, they will countersign the author s signature. Those countersignatures will then be embedded in the author s signature as unsigned attributes. Each countersignature must comply with a corresponding entry in the Authorization Requirements attribute. The Authorization Requirements attribute is structured as a list of required countersignatures. Each entry contains a set of required signatory attributes, a signatory identity reference or both. The set of required signatory attributes specifies which attributes shall be present in the signatory s AC. In a similar way, the signatory identity reference is a reference to the required signatory s PKC. Figure 1 presents a possible ASN.1[ITU-T 2008a] structure for the CAdES version of the proposed attribute. A u t h o r i z a t i o n R e q u i r e m e n t s : : = SEQUENCE of R e q u i r e d C o u n t e r S i g E n t r y R e q u i r e d C o u n t e r S i g E n t r y : : = SEQUENCE { s i g n e r A t t r i b u t e s [ 0 ] SEQUENCE of A t t r i b u t e OPTIONAL, s i g n e r I d e n t i t y [ 1 ] S i g n e r I d e n t i t y OPTIONAL } S i g n e r I d e n t i t y : : = CHOICE { s i g n e r I d e n t i t y V 1 [ 0 ] S i g n i n g C e r t i f i c a t e, s i g n e r I d e n t i t y V 2 [ 1 ] S i g n i n g C e r t i f i c a t e V 2 } Figure 1. Authorization Requirements ASN.1 structure The signerattributes field in Figure 1 shall be consistent with Section of RFC 5755 [Farrell et al. 2010]. Attribute types are defined in Section 4.4 of RFC The types SigningCertificate and SigningCertificateV2 in figure 1 are defined in RFC 5035 [Schaad 2007]. The signerattributes and signeridentity fields are optional, but at least one of them must be present in a RequiredCounterSigEntry instance. The validation process of a digital signature that contains an Authorization Requirements attribute begins precisely with that attribute. First, the presence of all required countersignatures in the creator s signature unsigned attributes section is assured. Next, each countersignature is validated. This includes the signature and Certification Path validation of both the signatory s PKC and AC. Then, these certificates are evaluated against the criteria specified in the requirements. If they all meet the requirements, the signatories authorization is acknowledged and the rest of the signature validation proceeds as usual. It should be noted that if one of the countersignatures is invalid or does not meet

5 the requirements, the document cannot be considered valid. Figure 2 shows the structure of a signed document for a hypothetic contract between university A and company B. In this example, the document must be signed by two people from the university, a Financial Manager and a Department Supervisor, and one person from the company, the company Director. These constraints are specified using the Role attribute type, which is defined in ISO/IEC [ITU-T 2008b]. The Role shall have the same value in the authorization requirements and the signatory s AC. Figure 3 shows the ASN1 representation of the Authorization Requirements attribute for this specific example. Since, for now, there are no OIDs defined for the types Authorization Requirements and RequiredCounterSigEntry, these appear only as sequences in the represented structure. signs Authorization Requirements RequiredCounterSigEntry Creator Signature signerattributes Signed Attributes Contract Role: Director Authorization Requirements... RequiredCounterSigEntry signerattributes Unsigned Attributes Role: Financial Manager 1st Countersignature 2nd Countersignature RequiredCounterSigEntry 3rd Countersignature... contains matches AC attribute signerattributes Role: Department Supervisor signs University A PKC AC PKC AC PKC AC Company B Department Supervisor Finacial Manager Director Figure 2. Contract Signature 5. Discussion It may seem natural to specify the identity and the authorization constraints of required signatories directly in the document s text. This may even be appropriate if those constraints are meant to be checked manually. However, automated validation of the signatories identity and authorization becomes very tricky when the constraints are specified in

6 0 103: SEQUENCE { 2 38: SEQUENCE { 4 36: SEQUENCE { 6 34: SEQUENCE { 8 3: OBJECT IDENTIFIER role ( ) 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 ( ) 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 ( ) 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.

7 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

8 - Part 1: PDF 1.7. Number ISO st edition. Chadwick, D. W. and Otenko, A. (2002). The permis x.509 role based privilege management infrastructure. In Proceedings of the seventh ACM symposium on Access control models and technologies, SACMAT 02, pages , New York, NY, USA. ACM. Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and Polk, W. (2008). Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280 (Proposed Standard). da Silva, N. (2011). Preservação por longo prazo de assinaturas digitais. Master s thesis, Universidade Federal de Santa Catarina. Eastlake, D. E., Reagle, J. M., and Solo, D. (2002). XML-signature syntax and processing. World Wide Web Consortium, Recommendation REC-xmldsig-core ETSI (2010). XML Advanced Electronic Signatures (XAdES). Number TS edition. ETSI (2011). CMS Advanced Electronic Signatures (CAdES). Number TS edition. Farrell, S., Housley, R., and Turner, S. (2010). An Internet Attribute Certificate Profile for Authorization. RFC 5755 (Proposed Standard). Housley, R. (2009). Cryptographic Message Syntax (CMS). RFC 5652 (Standard). ITU-T (2008a). Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. Number ISO/IEC th edition. ITU-T (2008b). Information technology - Open systems interconnection - The Directory: Public-key and attribute certificate frameworks. Number ISO/IEC th edition. Moecke, C. T. (2011). Nbpki - uma icp baseada em autoridades notariais. Master s thesis, Universidade Federal de Santa Catarina. Schaad, J. (2007). Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility. RFC 5035 (Proposed Standard).