> For the complete documentation index, see [llms.txt](https://docs.editran.onesait.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.editran.onesait.com/documentacion-editran/publico-editranff-v6.2-windows-en/administrador-de-onesait-ecosystems-editran-ff/alta-de-perfiles/alta-de-aplicaciones-de-editran-ff.md). # Creation of Editran/FF Applications To register a new Editran/FF application, select the branch “*Applications*” and then access the menu “*Operations -> New*” menu will be accessed (also from the right-click context menu) or the button ![](https://content.gitbook.com/content/AKp9o4ESamTHpX42EKdv/blobs/3LzRvney7xTPWhLqVrc9/image1.png) from the toolbar. The parameters required by the system to register a new application are described below. * **Name:** identifier of the application to be registered. For the first character, the following characters are allowed: A...Z@#$. For the following ones, the following are possible: A...Z0...9@#$-{ * **Purpose:** applications can be either for signing or for verifying signatures. If the option *“New*” from the branches “*File signing*” or “*Signature verification*”, this field is filled in automatically. ![](https://content.gitbook.com/content/AKp9o4ESamTHpX42EKdv/blobs/UW1oTS3YBlvr1IwKYRqu/image2.png) **--- Signatures ---** * **Signature mode:** indicates the format of the signatures that will be generated from the application. The implemented modes are grouped into two types: PKCS#7 (the signature file has PKCS#7 format and extension *.p7b*) and XAdES (the signature file has XML format and extension .*xsig*). Within each of these signature formats there are in turn several variants, briefly described below: * **PKCS#7 detached:** the signature file does not include the original file. **It requires sending the data file and the signature file to the receiving/validation end.** * **PKCS#7 attached:** the signature file includes the data file. * **XAdES Detached Internal Implicit:** the signature file includes the data file. In this mode, the nodes of the data file and those of the signatures made on the file are placed at the same level under the root node. If the data file being signed is not in XML format, it is incorporated in base64. * **XAdES Detached Internal Explicit:** layout the same as described in implicit mode, but in this case the data file itself is not included, only its hash. This format is suitable for very large files. **It requires sending the data file and the signature file to the receiving/validation end.** * **XAdES Detached Internal Explicit One File:** it is a variation of the previous mode proprietary to Iberpay in which the data file is concatenated after the signature file, so both remain in the same physical file. This variant **only supports XML files and a single signature.** * **XAdES External Detached:** the signature file does not include the data file. It is a variation of the internal modes in which, instead of the data file, what is included is a URI address where the data file is physically located. * **XAdES Enveloped:** the signature file includes the data file. In this case the signature nodes are children of the data file node. With this mode **only XML format files can be signed.** * **XAdES Implicit Enveloping:** the signature file includes the data file. In this case the data file node is a child of the signature node. If the signed file is not XML, it is incorporated in base64. This format **only supports one signature.** * **XAdES Explicit Enveloping:** layout the same as described for implicit mode, but in this case the data file itself is not included, only its hash. This format is suitable for very large files. **It requires sending the data file and the signature file to the receiving/validation end**. This format **only supports one signature.** Below the combo with the signature modes, a field can be displayed whose label changes depending on which mode is selected. This field is informational; it is checked or unchecked automatically depending on the chosen signature mode, and cannot be configured by the Administrator. The information it provides is relevant when choosing the type of files that will be marked in the tab *Sending* of this dialog, which will be seen later. **Using any of the XAdES signature modes requires having a 32-bit Java 8 or later installation on the machine. In addition, that installation must necessarily include the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files** (from Release 1.8.0\_151 it is included by default). The functionality for the XAdES signature modes is carried out through the service *Editran Signature* *Services*, which must be correctly started (from *UserFF* it runs automatically if start\_xades.bat is configured properly), see **7.12.** * **Required signature validation:** Editran/FF offers two ways to establish the different sets of users that must sign the files. Depending on the needs of each entity, the signatures required for each file (both the number of signatures and the specific signers who can do it) can be defined through Users/Groups or Joint Rules: * **Users/groups** * A user can be part of a group or be outside all of them, but cannot participate in both ways simultaneously. * A user cannot be part of more than one group or set of users. * For each file to be considered sufficiently signed, all user sets must be met: users who are outside a group must always sign (this is the case for automatic users) and in each group the minimum number of signatures (required signatures) must be reached and the maximum number (allowed signatures) cannot be exceeded. * The maximum amount of the files that each user can sign in the application is fixed and does not depend on whether or not other signers act. The registration of groups is explained in detail in section **4.2.4.** * **Enable signing order:** this option will be checked when the signatures of the users associated with the application must be made in a determined sequence. If the order in which the users have to sign is irrelevant, this parameter should not be enabled. The level of each one will be set in the user profile in the application. * **Joint rules:** * Each user can be part of as many conditions as are necessary. * A file is considered sufficiently signed when one of the conditions is met. * Users who are not part of any condition will not be able to sign. Except for automatic users, who cannot participate in any of the rules and yet must always sign. * The maximum amount of the files that the user can sign in the application is not fixed; it can vary depending on who they sign with, that is, depending on the joint conditions in which they participate. Users will only be able to sign files whose amount does not exceed any of the limits established in the different conditions in which they are involved. * It is not possible to establish the order in which the signatures are made. The registration of joint conditions is explained in detail in section **4.2.6.** **--- Files ---** * **Directories:** by selecting the tabs in the table, the directories associated with the application can be configured. They are as follows: * **Files to sign/Received files:** when the purpose of the **application** is “***Sign”***, the **path of the data files**. This path accepts wildcard characters (‘\*’, ‘?’). When the purpose of the **application** is “*V**erify”*** signatures, a **directory path**will be written here, the one where the data files extracted from the signatures will remain (or the ones that accompany them in the modes that do not include them). * **Signatures:** stores the location of the file signatures: those generated in applications for signing and those received in applications for verifying. It may coincide with the data files directory. In this case, it is recommended to use regular expressions in the “Files to sign” tab to prevent the signatures from being considered files to sign. * **Sending:** only for applications whose purpose is “*Sign*” and that are to be configured for sending with Editran. To use this functionality, first *Editran sending directory* must have been completed in the menu *Administrator -> General settings -> “Miscellaneous” tab,* see **4.1.1.1,.** The tab *Sending* shows three selectable options, *Data, Signatures* and *Enablement* and, as long as one of them has been checked, also a directory. * The selectable options refer to the type of files that will be sent by Editran (version 5.2.1 and later) to the other end. *Enablement* can only be selected in applications configured with *Enablement -> Yes* and only if previously *Signatures*, otherwise it will appear disabled. **If what is going to be sent to the other end are the signatures, consult the text under the signature mode to decide whether the data files must also be sent.** * The directory is where Editran will look for the files to be sent. It is a subdirectory under the one indicated in the *General settings* and whose name is that of the application. This path is composed automatically and cannot be modified. The files will be moved to this directory immediately and automatically: * In applications configured with *Enablement -> Yes*, when the application is enabled. * In applications configured with *Enablement -> No*, when all files in the application reach the required number of signatures (according to the profiles) and all of them are correct. The sending directory must be accessible from the signing workstations (just like the data and signatures directories) since the move will be triggered from one of them (the one that enables, in the first case, or the one that performs the last required signature on the last of the application files, in the second case). Once the files are in the sending directory, the validation of the application status is performed on this directory. The signing process for new application files is stopped (no user sees new files pending signature) while files exist in this directory. When the application files are in this directory, Editran/FF will validate the application signatures one last time and Editran, version 5.2.1 and later, will send only the files of the selected types (Data, Signatures and/or Enablement), according to the following criterion: * In applications configured with *Enablement -> Yes*, if everything is found to be correct in the pre-send verification, the files corresponding to the selected types are sent. If everything is correct but there are also files unrelated to that enablement, these are moved to a subdirectory called *RetiradosEditran* and the files corresponding to the selected types are sent. However, if the pre-send verification ends with an error because one of the signatures mentioned in the enablement file is found to be incorrect, or if any data file, signature file or the enablement file is missing, nothing is sent. In other words, in this type of application, if all the information contained in the enablement file is not correct, nothing is sent, not even the application files that do have the necessary and correct signatures. *For example, if the application APLICACION consists of FICHERO1, FIRMAFICHERO1, FICHERO2,* *FIRMAFICHERO2 and APLICACIÓN.p7b and sending Signatures has been configured:* * *If the pre-send verification concludes that everything is correct,* *FIRMAFICHERO1 and FIRMAFICHERO2 are sent.* * *If the pre-send verification concludes that FIRMAFICHERO1 is correct but* *FIRMAFICHERO2 is incorrect, nothing is sent.* * *If the pre-send verification concludes that everything is correct but in the directory* *of sending, NUEVOFICHERODESCONOCIDO is also found,* *NUEVOFICHERODESCONOCIDO is withdrawn and FIRMAFICHERO1 and FIRMAFICHERO2 are sent.* * In applications configured with *Enablement -> No*, it is verified that each file has the required signatures and that all of them are correct. If the verification is correct, the corresponding file type is sent, but if it is not, both that file and its signatures are moved to *RetiradosEditran*. In other words, in this type of application, the file types corresponding to the files that do have the necessary and correct signatures are sent and the rest are removed. *For example, if the application APLICACION consists of FICHERO1, FIRMAFICHERO1, FICHERO2* *and FIRMAFICHERO2 and sending Signatures has been indicated:* * *If the pre-send verification concludes that FIRMAFICHERO1 is correct and* *FIRMAFICHERO2 is incorrect, FICHERO2 and FIRMAFICHERO2 are moved to* *RetiradosEditran and FIRMAFICHERO1 is sent.* * *If the pre-send verification concludes that FIRMAFICHERO1 and FIRMAFICHERO2* *are correct but in the directory there is also* *NUEVOFICHERODESCONOCIDO, NUEVOFICHERODESCONOCIDO is withdrawn and* *FIRMAFICHERO1 and FIRMAFICHERO2 are sent.* In all cases, a report called *\[Application Name].editran* is created in the sending directory, which collects the files that have been sent and the associated ones that have not been sent. If SMTP email sending has been configured in the menu *General settings* and an email address has been configured in the application, the product will send informational and incident emails related to this functionality. Once sending with Editran is finished, the files and the report are moved to a subdirectory under this one called *SentEditran*. At this point the signing process can be resumed with the new files that exist in the files-to-sign directory. **To use this functionality with Editran** version 5.2.1 and later, **the necessary services must be running (EditranFF and/or Editran Signature Services, if the signatures are in XAdES modes).** If the version of Editran in use is earlier than 5.2.1, in EditranFF everything must be configured in this tab as described so that the files are moved to this directory. In Editran, the directory from which the files must be collected will be updated with the directory collected in this tab and for sending it will proceed as it has been doing until now. * **Move/Reject:** is the default directory to which the rejected data files will be moved, that is, those removed from the signing circuit by the users associated with the application who have permission to do so. If this field is left blank, the users granted such permission will be able to move the files to any directory visible from their computer for which they have write permission. * **Template (in applications for “*****Sign*****”) / XAdES Policy (in applications for “*****Verify”):*** when any one of the XAdES signature modes has been selected, the location of the **template** to be used must be defined here, **if the application is for “*****Sign”***, or the **policy, if the application is for “*****Verify*****” and the protection level used in the signatures is EPES.** Templates are XML documents, according to Editran/FF's proprietary schema and delivered in the distribution (in *XAdES/rsc*), which bring together a set of characteristics that are configurable for the chosen signature mode, such as protection level (BES or EPES), SHA version for obtaining the document hash, SHA version of the RSA algorithm with which it is signed, mandatory tags, etc. The product is distributed with different templates for each signature mode with the most commonly used configurations; they are found in the directory *XAdES/templates* of the installation. The policy file is another XML file, this time according to a proprietary XAdES schema, which contains the characteristics required to consider received signatures correct. In the XAdES/policies directory of the installation is the policy file of the General State Administration (AGE). List of signature modes and corresponding templates/policy: | **Signature mode** | **Template (signing applications)** | **Policy (applications for signature verification)** | | --------------------------------------------- | ----------------------------------- | ---------------------------------------------------- | | **XAdES Detached Internal Implicit** | pln-di-i-BES.xml | No policy | | | pln-di-i-EPES-AGE-v1.9.xml | plt-firma-AGE-v1-9.xml | | **XAdES Detached Internal Explicit** | pln-di-e-BES.xml | No policy | | **XAdES Detached Internal Explicit One File** | pln-di-e-unfich-BES.xml | No policy | | **XAdES Enveloped** | pln-envped-BES.xml | No policy | | | pln-envped-EPES-AGE-v1.9.xml | plt-firma-AGE-v1-9.xml | | **XAdES Implicit Enveloping** | pln-envping-i-BES.xml | No policy | | **XAdES Explicit Enveloping** | pln-envping-e-BES.xml | No policy | If none of the installation templates fits the required needs, another one can be written, always complying with the indicated schema, and referenced in this field. When the protection level to be used in the exchanged signatures is EPES, in this field the signing end will place a template with EPES and the validating end will place the policy file. Using at the signing end the templates in the XAdES/templates directory with “EPES-AGE” in the name guarantees compliance with the AGE policy at the receiving and validating end of those signatures. On the other hand, if the validating end is going to use BES as the protection level, it will leave this field blank and the signing end will indicate a template for BES protection level (in the distribution templates, those are all the ones with “BES” in the name). When a new application is registered and this field is blank, selecting each signature mode in the combo automatically writes in this field the corresponding template among those included in the product. In the modes for which there is a BES template and an EPES template, the first one is assigned by default, but the value can be changed. * **Viewer/Validator:** this parameter will indicate the format of the files that will be validated, viewed and signed in this application. If you do not want the content to be displayed before signing (an option not recommended) or if you want to mix files of different formats in the “*Files to be signed*” directory, you must select \ in the combo. The combo shows all the viewer and validator modules included in the product, see section **6.1. When the viewer to be used is the Transfers standard (both in plain format and XML format), only the Summary program can be chosen here (it only shows the header and the totals of the file). Then, in the User – Application profile of those users who must view the full content of the file (the individual transfers), the HR module will be selected, leaving the Summary module for the rest, which is the one that will appear by default.** * **Maximum total amount allowed in the files (€):** this parameter allows limiting the maximum amount of the files that can be signed. **--- Certificates ---** ***Verify certification chain:*** its selection triggers the validation (in terms of structure, content, use and expiration date) of all authority certificates (root and intermediate) in the certification chain of the one used for signing. This process is mandatory for XAdES signature modes, so this parameter will be checked automatically when one of those modes is selected. **Verify revocation status:** its selection triggers the validation of the revocation status of the certificate chosen for signing, that is, to know whether the authority that issued it still considers it valid or not. The place where this information must be verified is part of the information contained in the certificates. If the location is an https address, the machine from which the validation is performed must have internet access and the parameters written with XAdES/bin/configuracion\_xades.cfg must be correctly configured. **--- Enablement ---** * **Yes / No:** the enablement file is a summary file with EditranFF's proprietary format. It collects the name of each application file found in the data directory, the DNs of the certificates with which it was signed, the name of the resulting signature file and, where applicable, a comment informing that signatures are missing. This file will be created in applications where option “*Yes*” is checked and will not be created otherwise. The presence of incorrect or invalid signatures in the application is incompatible with the generation of this file. It can be created manually or automatically and only by users who have permission to do so. The enablement file, with the content described above, is signed by the user who generates it, is stored in the application signatures directory with the same name as the application and the extension .*p7b*. If the application is for verifying signatures, the parameter indicates whether the enablement file will be received or not. * **Automatic enablement:** when option “*Yes*” has been selected, this option can also be checked so that the generation of the enablement file is triggered after the last required signature for the files of an application, provided that the user who made that last signature has permission to enable. Although the process in this case is triggered automatically, the user may cancel its generation if desired. If this option is not checked, the application will remain without the enablement file until a user of the application, with the appropriate permission, generates it manually. * **Post-enablement process:** this parameter can be used to indicate the name of a program or *batch* file that carries out a certain task to be launched after enablement, if the application is for signing, or after acceptance if it is for signature verification. * **E-Mail Notifications:** as long as email sending has been configured (see **4.1.1.1**) various generic notifications from EditranFF will be received at this address, for example when the application is enabled, when a file is rejected, etc. **The fields “*****Compression*****” and “*****Encryption*****” in the “*****Files to be signed*****”, the “*****Sending”, “Move/Reject*****” and *****“Certificate for encryption*****” of the table “*****Directories*****” and field “*****Automatic enablement*****” are specific to signing applications and are therefore disabled when an application whose purpose is to verify signatures is defined.** Once the form has been completed, you will proceed to “*Save*”, thus leaving the new application stored with these parameters in “*aplicFF.cfg*” and it will be added in the tree to one of the subbranches “*File signing*” or “*Of signature verification* *signatures*” --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.editran.onesait.com/documentacion-editran/publico-editranff-v6.2-windows-en/administrador-de-onesait-ecosystems-editran-ff/alta-de-perfiles/alta-de-aplicaciones-de-editran-ff.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.