EBML: Extensible Binary Markup Language

Deja un comentario

EBML,  Extensible Binary Meta-Language (o Extensible Binary Meta Language) es un nuevo lenguage de marcado de información conceptualmente semejante al XML pero diseñado para ser más compacto y codificar datos binarios.

Muchos lo ocnsideran una variante del concepto de «reinventar la rueda» puesto que  esta necesidad está tradicionalmente cubierta con la notación ASN.1 Abstract Syntax Notation One (notación sintáctica abstracta 1).

Sin embargo es interesante conocerla, por lo que se incluye seguidamente un borrador de la especcificación:

 

RFC v1.0

 
Draft                                                       M. Nilsson
Document: ebml-1.0.txt                                 15th March 2004
 
 
		  Extensible Binary Markup Language
 
Copyright
 
   Copyright (C) Martin Nilsson 2004. All rights reserved.
 
 
Abstract
 
   The extensible binary markup language, EBML, is a binary language
   for storing hierarchical, typed in data in a compact, yet easily
   parsed format.
 
 
About this document
 
   This document is currently in its draft stage and is subject to
   changes. The contents should not be relied upon for
   implementational purposes.
 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119
   [RFC2119].
 
   The definitions in this document uses ABNF [ABNF]. Note that string
   terminals are case insensitive in ABNF. The interpretation of
   binary values has been slightly altered so that every bit must be
   explicitly printed, e.g. %b0 is one zero bit while %b000 represents
   three zero bits. The following (re)definitions are used throughout
   this document.
 
     BIT  = %b1 / %b0
     BYTE = OCTET
     WSP  = SP / HTAB / CR / LF
 
 
1.  Introduction
 
   The Extensible Binary Markup Language EBML was designed to be a
   simplified binary version of XML for the purpose of storing and
   manipulating data in a hierarchical form with variable field
   lengths. Specifically EBML was designed as the framework language
   for the video container format Matroska. Some of the advantages of
   EBML are:
 
   - Possibility for compatibility between different versions of
     binary languages defined in EBML. A rare property of binary
     format that otherwise often needs careful consideration
     beforehand.
 
   - Unlimited size of data payload.
 
   - Can be both generated and read as a stream, without knowing the
     data size beforehand.
 
   - Often very space efficient, even compared to other binary
     representations of the same data.
 
   Some of the EBML disadvantages are:
 
   - No references can be made between EBML files, such as includes or
     inherits. Every EBML document is a self contained entity. The
     data stored in EBML may of course reference other resources.
 
   - No compositioning process to merge two or more EBML languages
     currently exists.
 
   This document describes the EBML binary syntax, its semantic
   interpretation and the syntax of a textual document type definition
   format used to define the rules and constraints of an EBML
   language. BNF is used throughout this document to augment the
   description and make it more formalized. It must however be noted
   that two different formats are described in this document, with two
   different BNFs. One for the binary format in chapter 2 and one for
   the document type definition in the rest of the document. To avoid
   confusion different token names has been chosen. The BNFs can be
   viewed in full in the appendices.
 
 
2.  Structure
 
   Syntactically an EBML document is a list of EBML elements. Each
   element has three parts; an element ID, a size descriptor and the
   element data payload. The element data payload is then either data,
   implicitly typed by the element ID, or a list of EBML elements.
 
     EBML       = *ELEMENT
     ELEMENT    = ELEMENT_ID SIZE DATA
     DATA       = VALUE / *ELEMENT
     ELEMENT_ID = VINT
     SIZE       = VINT
 
   EBML uses big endian/network order byte order, i.e. most
   significant bit first. All of the tokens above are byte aligned.
 
 
2.1.  Variable size integer
 
   For both element ID and size descriptor EBML uses a variable size
   integer, coded according to a schema similar to that of UTF-8
   [UTF-8] encoding. The variable size integer begins with zero or
   more zero bits to define the width of the integer. Zero zeroes
   means a width of one byte, one zero a width of two bytes etc. The
   zeroes are followed by a marker of one set bit and then follows the
   actual integer data. The integer data consists of alignment data
   and tail data. The alignment data together with the width
   descriptor and the marker makes up one ore more complete bytes. The
   tail data is as many bytes as there were zeroes in the width
   descriptor, i.e. width-1.
 
     VINT           = VINT_WIDTH VINT_MARKER VINT_DATA
     VINT_WIDTH     = *%b0
     VINT_MARKER    = %b1
     VINT_DATA      = VINT_ALIGNMENT VINT_TAIL
     VINT_ALIGNMENT = *BIT
     VINT_TAIL      = *BYTE
 
   An alternate way of expressing this is the following definition,
   where the width is the number of levels of expansion.
 
     VINT = ( %b0 VINT 7BIT ) / ( %b1 7BIT )
 
   Some examples of the encoding of integers of width 1 to 4. The x:es
   represent bits where the actual integer value would be stored.
 
   Width  Size  Representation
     1    2^7   1xxx xxxx
     2    2^14  01xx xxxx  xxxx xxxx
     3    2^21  001x xxxx  xxxx xxxx  xxxx xxxx
     4    2^28  0001 xxxx  xxxx xxxx  xxxx xxxx  xxxx xxxx
 
 
2.2.  Element ID
 
   The EBML element ID is encoded as a variable size integer with, by
   default, widths up to 4. Another maximum width value can be set by
   setting another value to EBMLMaxIDWidth in the EBML header. See
   section 5.1. IDs are always encoded in their shortest form, e.g. 1
   is always encoded as 0x81 and never as 0x4001. This limits the
   number of IDs in every class with the number of IDs in the previous
   classes. Furthermore, values with all data bits set to 1 and all
   data bits set to 0 are reserved, hence the effective number of IDs
   are as follows for different widths. Note that the shortest
   encoding form for 127 is 0x407f since 0x7f is reserved.
 
   Class  Width  Number of IDs
     A      1    2^7-2     =         126
     B      2    2^14-2^7  =      16 256
     C      3    2^21-2^14 =   2 080 768
     D      4    2^28-2^21 = 266 338 304
 
 
2.3.  Element data size
 
   The EBML element data size is encoded as a variable size integer
   with, by default, widths up to 8. Another maximum width value can
   be set by setting another value to EBMLMaxSizeWidth in the EBML
   header. See section 5.1. There is a range overlap between all
   different widths, so that 1 encoded with width 1 is semantically
   equal to 1 encoded with width 8. This allows for the element data
   to shrink without having to shrink the width of the size
   descriptor.
 
   Values with all data bits set to 1 means size unknown, which allows
   for dynamically generated EBML streams where the final size isn't
   known beforehand. The element with unknown size MUST be an element
   with an element list as data payload. The end of the element list is
   determined by the ID of the element. When an element that isn't a
   sub-element of the element with unknown size arrives, the element
   list is ended.
 
   Since the highest value is used for unknown size the effective
   maximum data size is 2^56-2, using variable size integer width 8.
 
 
2.4.  Values
 
   Besides having an element list as data payload an element can have
   its data typed with any of seven predefined data types. The actual
   type information isn't stored in EBML but is inferred from the
   document type definition through the element ID. The defined data
   types are signed integer, unsigned integer, float, ASCII string,
   UTF-8 string, date and binary data.
 
     VALUE = INT / UINT / FLOAT / STRING / DATE / BINARY
 
 
     INT = *8BYTE
 
   Signed integer, represented in two's complement notation, sizes
   from 0-8 bytes. A zero byte integer represents the integer value 0.
 
 
     UINT = *8BYTE
 
   Unsigned integer, sizes from 0-8 bytes. A zero byte integer
   represents the integer value 0.
 
 
     FLOAT = *1( 4BYTE / 8BYTE / 10BYTE )
 
   IEEE float [FLOAT], sizes 0, 4, 8 or 10 bytes. A zero byte float
   represents the float value 0.0.
 
 
     PADDING = %x00
     STRING  = *BYTE *PADDING
 
   UTF-8 [UTF-8] encoded Unicode [UNICODE] string. A string MAY be
   zero padded at the end. Note that a string can be of zero length.
 
 
     DATE = 8BYTE
 
   Signed, 64-bit (8 byte) integer describing the distance in
   nanoseconds to the beginning of the millennium (2001-01-01 00:00:00
   UTC).
 
 
     BINARY = *BYTE
 
   Binary data, i.e. not interpreted at the EBML level.
 
 
3.  Semantic interpretation
 
   Every element has several properties defined in the document type
   definition, which are needed for the correct syntactical and
   semantic handling of the information. These properties are name,
   parent, ID, cardinality, value restrictions, default value, value
   type and child order.
 
   To syntactically parse EBML data we need to know the element value
   types, and to semantically interpret that data we also need to know
   the element IDs and element names. Elements can have a default
   value, so for the final presentation of the parsed EBML data
   elements that wasn't stored in the data may show up. Finally
   elements may have restrictions in terms of which parent or parents
   they may have, the number of times they may occur in the EBML data,
   their order in the document and various additional restrictions of
   their data payload.
 
 
3.1.  Name property
 
   The name is the symbolic identifier of an element and has a 1:1
   mapping to the element ID. Only alphanumeric characters and
   underscores may be used for the name. It may not start with a
   number. Names are treated case insensitive, i.e. "Name" is the same
   identifier as "name".
 
     NAME = [A-Za-z_] 1*[A-Za-z_0-9]
 
 
3.2.  Value type property
 
   There is no way of knowing whether or not to look for sub elements
   with only the information presented in the EBML data. Hence the
   element value type is the most important information in the EBML
   DTD. In addition to the value types defined in section 2.4 an
   element can also be of the type "container", which simply means
   that its content is more elements.
 
 
3.3.  ID property
 
   Every element must have an ID associated, as defined in section
   2.2.  These IDs are expressed in the hexadecimal representation of
   their encoded form, e.g. 1a45dfa3.
 
     ID = 1*( 2HEXDIG )
 
 
3.4.  Default value property
 
   Every non-container MAY be assigned a default value. If so, its
   value will be added to the interpretation of the EBML data if no
   element with another value exists in the data.
 
   As an example, consider this EBML DTD:
 
   Weight := 4101 {
     WeightValue := 41a1 uint;
     WeightUnit  := 41a2 string [ def:"kilogram" ];
   }
 
   If the Weight element only contains the WeightValue element, the
   WeightUnit element with value "kilogram" will be added when the
   information is semantically processed. A WeightUnit element with
   another value would of course override the default.
 
   The default value can also be a symbol referring back to a
   previously seen symbol. If however no such symbol has been seen,
   i.e. it has not been encoded into the EBML data and has no default
   value, the element will not be added as a child on the semantic
   level.
 
   Weight := 4101 {
     WeightValue := 41a1 uint;
     WeightUnit  := 41a2 string [ def:WeightUnit ];
   }
 
   In this example all Weight elements will use the same weight unit
   as the previous one. To ensure that the first one has a value its
   cardinality should be set to "1". See section 3.6.
 
     DEFAULT = INT_DEF / UINT_DEF / FLOAT_DEF / STRING_DEF /
               DATE_DEF / BINARY_DEF / NAME
 
     DATE_VALUE = *1DIGIT 2DIGIT 2DIGIT
                  *1(%x54 2DIGIT ":" 2DIGIT ":" 2DIGIT
                     *1( "." *1DIGIT ))
 
     INT_DEF    = *1"-" 1*DIGIT
     UINT_DEF   = 1*DIGIT
     FLOAT_DEF  = INT "." 1*DIGIT *1( "e" *1( "+"/"-" ) 1*DIGIT )
     DATE_DEF   = INT_DEF / DATE_VALUE
 
     STRING_DEF = ("0x" 1*( 2HEXDIG )) / ( %x22 *(%x20-7e) %x22 )
     BINARY_DEF = STRING_DEF
 
   The date default value is either described as the integer in its
   encoded form or in the ISO short format; YYYYMMDD followed by the
   string literal T, the time as HH:MM:DD and finally and optionally
   the fractions as .F with an optional numbers of F for
   precision. Some examples:
 
     ExampleInt := c0 int [ def:-114; ]
     ExampleUInt := c1 uint [ def:0; ]
     ExampleFloat := c2 float [ def:6.022E23 ]
     ExampleDate := c3 date [ def:20011224T15:00:03.21; ]
     ExampleBinary := c5 binary [ def:0x4944337632; ]
     ExampleString := c6 string [ def:"Sweden"; ]
 
 
3.5.  Parent property
 
   To place the elements in a hierarchical structure we need
   relational information about the elements. In the EBML DTD this is
   expressed as the possible parents an element may have. This can be
   expressed in two ways: an explicit list of allowed parents or a
   generic definition of allowed insertion depth.
 
     PARENTS = NAME / ( NAME "," PARENTS )
     LEVEL   = 1*DIGIT *1( ".." *DIGIT )
 
   An element with neither parents nor level defined is assumed to
   exist on the top level in the EBML document. An element can not
   have both a parent and a level property.
 
   The following example contains two elements, Envelope and
   Letter. The Letter must, if it exists in the document, be a child
   of Envelope and Envelop must, if it exists in the document, reside
   at the top level.
 
     Envelope := a0 container;
     Letter := b0 string [ parent:Envelope; ]
 
   The following example expresses the exact same relationships, but
   in an abbreviated syntax.
 
     Envelope := a0 container {
       Letter := b0 string;
     }
 
   The following example shows that the abbreviated syntax can't be
   used to solve all relations. Here the Letter element can be a child
   in both the Envelope element and the Trashcan element. The explicit
   parent information is merged with the one expressed with the
   abbreviated syntax.
 
     Envelope := a0 container {
       Letter := b0 string [ parent:Trashcan; ];
     }
     Trashcan := a1 container;
 
   The following example demonstrates the usage of level instead of
   parent. The element Void may occur at any place in the EBML
   document.
 
     Void  := ec binary [ level:1..; card:*; ]
 
   This is an example similar to the one above, but using containers
   instead. The children of the parent to the SHA1 element may be
   pushed down to the level where "%children;" is, i.e. if used with
   the first Letter-Envelope example the Envelope may contain an SHA1
   element which may contain an SHA1Content element which may contain
   a Letter element. A container element with a level property MUST
   NOT use undefined size as described in section 2.3, since then the
   end of the element can not be determined in all cases.
 
     SHA1 := 190babe5 container [ level:1..; card:*; ] {
        SHA1Content := 20110f container {
          %children;
        }
        SHA1Hash := 20110e binary;
     }
 
 
3.6.  Cardinality property
 
   The cardinality of an element declares how many times an element
   may occur in its current scope. By default an element may only
   occur at most once in a scope, e.g. if the element Weight has been
   defined as a child to Brick, no more than one Weight element can be
   used in every Brick element. The cardinality can however be altered
   from the default to any of the following. Note that this affects
   all scopes that the element can be inserted into.
 
     Symbol   Interpretation
       *      Zero or more occurrences.
       ?      Zero or one occurrence (default).
       1      Exactly one occurrence.
       +      One or more occurrences.
 
     CARDINALITY = "*" / "?" / "1" / "+"
 
 
3.7.  Child order property
 
   The child order property only applies to container elements. It
   simply declares if the children of the element must appear in the
   order they are defined in or not. By default this restriction is
   imposed on all children to all elements. The advantage of ordered
   elements in combination with default values is that the EBML
   decoder will know immediately once an element is skipped and can
   output the appropriate default value instead.
 
     YES     = "yes" / "1"
     NO      = "no" / "0"
     ORDERED = YES / NO
 
 
3.8.  Value restriction properties
 
   Every element may impose additional constraints upon its
   value. These constraints are only used to validate data during
   encoding and makes no difference for the decoding or interpretation
   of the encoded data. The available constraints and syntax differs
   between different types of elements.
 
 
3.8.1.  Range
 
   The range of an element value determines the allowed values that
   the element value may have. The range is expressed as one or more
   specific values or spans of allowed values, with the exception of
   floats and dates where only spans are allowed.
 
     RANGE_LIST = RANGE_ITEM / ( RANGE_ITEM S "," S RANGE_LIST )
     RANGE_ITEM = INT_RANGE / UINT_RANGE / FLOAT_RANGE /
                  STRING_RANGE / DATE_RANGE / BINARY_RANGE
 
   For integers the range is a list of values and open or closed
   ranges, e.g. "0,1", "1..5" and "..-1,1..". The final allowed range
   is a union of all listed ranges. If a value matches any of the
   listed ranges it is considered valid.
 
     INT_RANGE = INT_DEF / ( INT_DEF ".." ) / ( ".." INT_DEF ) /
                 ( INT_DEF ".." INT_DEF )
 
   Unsigned integers is similar, but can not have its range open to
   the left.
 
     UINT_RANGE  = UINT_DEF *1( ".." UINT_DEF )
 
   Floats can have both inclusive and exclusive end points of its
   ranges.
 
     FLOAT_RANGE = ( ("<" / "<="/ ">" / ">=") FLOAT_DEF ) /
                   ( FLOAT_DEF "<"/"<=" ".." "<"/"<=" FLOAT_DEF )
 
   Date ranges has the same syntax and semantics as integer ranges,
   except that the actual date can be described either as an integer
   or in ISO short format.
 
     DATE_RANGE = ( DATE_DEF ".." ) / ( ".." DATE_DEF ) /
                  ( DATE_DEF ".." DATE_DEF )
 
   String and binary ranges limits the range for each character/byte
   in the string. Note that in the string case this is for the
   unencoded unicode data, i.e. the possible range is larger than
   0-255, which is the bounding range for binary data.
 
     STRING_RANGE = UINT_RANGE
     BINARY_RANGE = UINT_RANGE
 
 
3.8.2.  Size
 
   The size of an element value is simply the number of bytes it
   occupies in its encoded form. That means that the size of a string
   element value need not be the same as the string length.
 
     SIZE_LIST = UINT_RANGE / ( UINT_RANGE S "," S SIZE_LIST )
 
 
4.  Document Type Definition
 
   The EBML document type definition, EDTD, is an ASCII based language
   that allows for the constraints and relations described in chapter
   3 to be described in a way that is both human and computer
   readable. Syntactically it consists of blocks, not unlike most
   programming languages, which contains definitions/declarations
   similar to BNF. The format is largely whitespace insensitive, case
   insensitive and supports both C-style (LCOMMENT) and C++-style
   (BCOMMENT) comments. The BNF lines in this chapter is somewhat
   simplified for readability compared to the complete BNF in Appendix
   B.
 
     COMMENT = LCOMMENT / BCOMMENT
     S       = *WSP / ( *WSP COMMENT *WSP ) ; Optional white spaces
 
   On the top level of the EDTD only three different blocks are
   currently defined, header declarations, type definitions and
   element definitions.
 
     DTD     = *( S / HBLOCK / TBLOCK / EBLOCK )
 
 
4.1.  Header declarations
 
   The meaning of the header declaration is to declare what values
   should be put into the elements of the header, should they differ
   from the default values. The header declaration block is written as
   "declare header" followed by curly brackets that encloses the block
   of statements. The actual statements are very straightforward, the
   element name followed by ":=" followed by the value, as described
   in section 3.4, followed by ";". There MUST only be one header
   declaration block in a DTD.
 
     HBLOCK    = "declare" WSP "header" S "{" *(S / STATEMENT) "}"
     STATEMENT = NAME S ":=" S DEFS S ";"
 
   Since the DocType element has no default value it MUST be declared
   in the EDTD. It is RECOMMENDED that the EBMLVersion is also
   declared. Such a declaration could look like this:
 
     declare header {
       DocType := "xhtml";
       EBMLVersion := 1;
     }
 
 
4.2.  Type definitions
 
   Type definitions is a way to create types with more mnemonic names,
   making the DTD both smaller and easier to read. The type
   definitions block is written as "define types" followed by a block
   of statements enclosed in curly brackets. Each statement is a type
   name followed by ":=" followed by the type on which this type
   should be based on, optionally followed by a list of properties,
   enclosed in angle brackets. The type names follows the same rules
   as element names, but lives in another namespace, i.e. there may be
   an element with the same name as a type.
 
     TBLOCK = "define" S WSP "types" S "{" *(S / DTYPE) "}"
     DTYPE  = NAME S ":=" S TYPE S (PROPERTIES S *1";")/";"
 
   The base type may be another defined type, as long as the
   definitions are made in order, as shown in the following example.
 
     define types {
       digits := int;
       number := digits;
     }
 
   The type definition then both allows for types as described in
   section 2.4 and NAME, which refers to types previously defined in
   the document.
 
     TYPE  = VTYPE / CTYPE
     VTYPE = "int" / "uint" / "float" / "string" / "date" /
     	     "binary" / NAME
     CTYPE = "conainer" / NAME
 
   If the type definition has no list of properties, the statement is
   ended with ";". If the it has a property list, ending the statement
   with ";" is optional.
 
     PROPERTIES = "[" S 1*PROPERTY S "]"
     PROPERTY   = PROP_NAME S ":" S PROP_VALUE S ";"
 
   Some examples:
 
     crc32 := binary [ size:4; ]
     sha1  := binary [ size:20; ]
     bool  := uint [ range:0..1; ]
     us_printable := binary [ range:32..126; ]
 
 
4.2.  Element definitions
 
   The element definitions is the real purpose of the DTD. The element
   definitions block is written as "define elements" followed by a
   block of statements enclosed in curly brackets. Each statement can
   be either a simple statement similar to the type definition
   statements, or a block statement, containing more statements.
 
     EBLOCK   = "define" WSP "elements" S "{" *(S / ELEMENT) "}"
     DELEMENT = VELEMENT / CELEMENT / "%children;"
 
   The simple statements are typically used for value elements and
   consists of a name followed by ":=", id, type and optionally
   properties.
 
     VELEMENT = NAME S ":=" S ID WSP S TYPE S (PROPERTIES S *1";")/";"
 
   The block version of the element statements are only used to
   express parent-children relations. See section 3.5.
 
     CELEMENT = NAME S ":=" S ID WSP S "container" S *1PROPERTIES S
                ("{" *DELEMENT "}")/";"
 
 
5.  EBML standard elements
 
   EBML defines a small set of elements that can be used in any EBML
   application. An EBML document MUST begin with an EBML header
   consisting of the EBML element. Generally speaking it would be
   possible to define default values to all elements in the EBML
   element in the document type definition for an application, and
   thus being able to represent the entire header without have a
   single byte written. However, in order to be able to identify EBML
   documents between applications it is REQUIRED that all EBML
   elements whose values differs from the standard defaults in this
   document, are written in EBML data. In practice that means that at
   least the DocType is always stored in all EBML documents.
 
5.1.  EBML
 
   The EBML element is a container for the EBML header.
 
     EBML := 1a45dfa3 container [ card:+; ]
 
 
5.1.1.  EBMLVersion
 
   EBMLVersion is the version of EBML to which the document conforms
   to.
 
     EBMLVersion := 4286 uint [ def:1; parent:EBML; ]
 
 
5.1.2.  EBMLReadVersion
 
   The minimum EBML version a parser has to support in order to read
   the document.
 
     EBMLReadVersion := 42f7 uint [ def:1; parent:EBML; ]
 
 
5.1.3.  EBMLMaxIDWidth
 
   The maximum width of the IDs used in this document. It is
   RECOMMENDED to not have wider IDs than 4. EBMLMaxIDWidth may be
   larger than any actual width used in the document.
 
     EBMLMaxIDWidth := 42f2 uint [ def:4; parent:EBML; ]
 
 
5.1.4.  EBMLMaxSizeWidth
 
   The maximum width of the size descriptors used in this document. It
   is RECOMMENDED to not have wider size descriptors than 8.
   EBMLMaxSizeWidth may be larger than any actual width used in the
   document.
 
     EBMLMaxSizeWidth := 42f3 uint [ def:8; parent:EBML; ]
 
 
5.1.5.  DocType
 
   An ASCII string that identifies the type of the document.
 
     DocType := 4282 binary [ range:32..126; parent:EBML; ]
 
 
5.1.6.  DocTypeVersion
 
   DocTypeVersion is the version of document type to which the
   document conforms to.
 
     DocTypeVersion := 4287 uint [ def:1; parent:EBML; ]
 
 
5.1.7.  DocTypeReadVersion
 
   The minimum DocType version an interpreter has to support in order
   to read the document.
 
     DocTypeReadVersion := 4285 uint [ def:1; parent:EBML; ]
 
 
5.2.  CRC32
 
   The CRC32 container can be placed around any EBML element or
   elements. The value stored in CRC32Value is the result of the
   CRC-32 [CRC32] checksum performed on the other child elements.
 
     CRC32 := c3 container [ level:1..; card:*; ] {
       %children;
       CRC32Value := 42fe binary [ size:4; ]
     }
 
 
5.3.  Void
 
   The void element can be used as padding to prepare for more data,
   or to fill space when data has been removed. It should simply be
   ignored when the document is interpreted.
 
     Void  := ec binary [ level:1..; card:*; ]
 
 
6.  References
 
   [ABNF] D. Crocker, P. Overell, 'Augmented BNF for Syntax
   Specifications: ABNF', RFC 2234, November 1997.
 
      <url:ftp://ftp.isi.edu/in-notes/rfc2234.txt>
 
   [CRC32] International Organization for Standardization, 'ISO
   Information Processing Systems - Data Communication High-Level Data
   Link Control Procedure - Frame Structure", IS 3309, October 1984,
   3rd Edition.
 
   [FLOAT] Institute of Electrical and Electronics Engineers, 'IEEE
   Standard for Binary Floating-Point Arithmetic', ANSI/IEEE Standard
   754-1985, August 1985.
 
   [RFC2119] S. Bradner, 'Key words for use in RFCs to Indicate
   Requirement Levels', RFC 2119, March 1997.
 
      <url:ftp://ftp.isi.edu/in-notes/rfc2119.txt>
 
   [UNICODE] International Organization for Standardization,
   'Universal Multiple-Octet Coded Character Set (UCS), Part 1:
   Architecture and Basic Multilingual Plane', ISO/IEC 10646-1:1993.
 
      <url:http://www.unicode.org>
 
   [UTF-8] F. Yergeau, 'UTF-8, a transformation format of ISO 10646',
   RFC 3629, November 2003.
 
      <url:ftp://ftp.isi.edu/in-notes/rfc3629.txt>
 
 
Appendix A.  EBML BNF
 
     EBML    = *ELEMENT
     ELEMENT = ELEMENT_ID SIZE DATA
     DATA    = VALUE / *ELEMENT
 
     VINT = ( %b0 VINT 7BIT ) / ( %b1 7BIT )
 
     ; A more annotated but less correct definition of VINT
     ;
     ; VINT           = VINT_WIDTH VINT_MARKER VINT_DATA
     ; VINT_WIDTH     = *%b0
     ; VINT_MARKER    = %b1
     ; VINT_DATA      = VINT_ALIGNMENT VINT_TAIL
     ; VINT_ALIGNMENT = *BIT
     ; VINT_TAIL      = *BYTE
 
     ELEMENT_ID   = VINT
     SIZE         = VINT
 
     VALUE = INT / UINT / FLOAT / STRING / DATE / BINARY
 
     PADDING = %x00
 
     INT    = *8BYTE
     UINT   = *8BYTE
     FLOAT  = *1( 4BYTE / 8BYTE / 10BYTE )
     STRING = *BYTE *PADDING
     DATE   = 8BYTE
     BINARY = *BYTE
 
 
Appendix B.  EBML DTD BNF
 
   ; NOTE: This BNF is not correct in that it allows for more freedom
   ; than what is described in the text. That is because a 100%
   ; correct BNF would be almost unreadable. To be correct CELEMENT
   ; would be split into one ELEMENT token for every value type, and
   ; then each and every one of them would have their own PROPERTIES
   ; definition which points out only the DEF and RANGE for that value
   ; type. Some other shortcuts are noted in comments.
 
   LCOMMENT = "//" *BYTE (CR / LF) ; *BYTE is string without CR/LF
   BCOMMENT = "/*" *BYTE "*/" ; *BYTE is string without "*/"
   COMMENT  = LCOMMENT / BCOMMENT ; Line comment / Block comment
   S        = *WSP / ( *WSP COMMENT *WSP ) ; Optional white spaces
 
   DTD      = *( S / HBLOCK / TBLOCK / EBLOCK )
   HBLOCK   = "declare" S WSP "header" S "{" *(S / STATEMENT) "}"
   EBLOCK   = "define" S WSP "elements" S "{" *(S / DELEMENT) "}"
   TBLOCK   = "define" S WSP "types" S "{" *(S / DTYPE) "}"
 
   DELEMENT = VELEMENT / CELEMENT / "%children;"
   VELEMENT = NAME S ":=" S ID WSP S TYPE S (PROPERTIES S *1";")/";"
   CELEMENT = NAME S ":=" S ID WSP S "container" S *1PROPERTIES S
              ("{" *DELEMENT "}")/";"
 
   NAME     = [A-Za-z_] 1*[A-Za-z_0-9]
 
   ID       = 1*( 2HEXDIG )
 
   TYPE     = VTYPE / CTYPE
   VTYPE    = "int" / "uint" / "float" / "string" / "date" /
              "binary" / NAME
   CTYPE    = "conainer" / NAME
 
   PROPERTIES = "[" S 1*PROPERTY S "]"
   PROPERTY   = PARENT / LEVEL / CARD / DEF / RANGE / SIZE
 
   PARENT   = "parent" S ":" S PARENTS S ";"
   PARENTS  = NAME / ( NAME S "," S PARENTS )
 
   LEVEL    = "level"  S ":" S 1*DIGIT *(".." *DIGIT) S ";"
   CARD     = "card"   S ":" S ( "*" / "?" / "1" / "+" ) S ";"
 
   ORDERED  = "ordered" S ":" S ( YES / NO ) S ";"
   YES      = "yes" / "1"
   NO       = "no" / "0"
 
   DEF      = "def"    S ":" S DEFS S ";"
   DEFS     = ( INT_DEF / UINT_DEF / FLOAT_DEF / STRING_DEF /
                DATE_DEF / BINARY_DEF / NAME )
 
   RANGE    = "range" S ":" S RANGE_LIST S ";"
   RANGE_LIST = RANGE_ITEM / ( RANGE_ITEM S "," S RANGE_LIST )
   RANGE_ITEM = INT_RANGE / UINT_RANGE / FLOAT_RANGE /
                STRING_RANGE / DATE_RANGE / BINARY_RANGE
 
   SIZE       = "size" S ":" S SIZE_LIST S ";"
   SIZE_LIST  = UINT_RANGE / ( UINT_RANGE S "," S SIZE_LIST )
 
   ; Actual values, but INT_VALUE is too long.
   INT_V   = *1"-" 1*DIGIT
   FLOAT_V = INT "." 1*DIGIT *1( "e" *1( "+"/"-" ) 1*DIGIT )
   ; DATE uses ISO short format, yyyymmddThh:mm:ss.f
   DATE_V  = *1DIGIT 2DIGIT 2DIGIT
             *1(%x54 2DIGIT ":" 2DIGIT ":" 2DIGIT *1( "." *1DIGIT ))
 
   INT_DEF    = INT_V
   UINT_DEF   = 1*DIGIT
   FLOAT_DEF  = FLOAT_V
   DATE_DEF   = INT_DEF / DATE_V
   STRING_DEF = ("0x" 1*( 2HEXDIG )) / ( %x22 *(%x20-7e) %x22 )
   BINARY_DEF = STRING_DEF
 
   INT_RANGE   = INT_V / ( INT_V ".." ) / ( ".." INT_V ) /
                  ( INT_V ".." INT_V )
   UINT_RANGE  = 1*DIGIT *1( ".." *DIGIT )
   FLOAT_RANGE = ( ("<" / "<=" / ">" / ">=") FLOAT_DEF ) /
                   ( FLOAT_DEF "<"/"<=" ".." "<"/"<=" FLOAT_DEF )
   DATE_RANGE   = (1*DIGIT / DATE_V) *1( ".." *(DIGIT / DATE_V) )
   BINARY_RANGE = UINT_RANGE
   STRING_RANGE = UINT_RANGE
 
   STATEMENT = NAME S ":=" S DEFS S ";"
 
   ; TYPE must be defined. PROPERTIES must only use DEF and RANGE.
   DTYPE     = NAME S ":=" S TYPE S (PROPERTIES S *1";")/";"
 
 
Appendix C.  EBML Standard definitions
 
   define elements {
     EBML := 1a45dfa3 container [ card:+; ] {
       EBMLVersion := 4286 uint [ def:1; ]
       EBMLReadVersion := 42f7 uint [ def:1; ]
       EBMLMaxIDLength := 42f2 uint [ def:4; ]
       EBMLMaxSizeLength := 42f3 uint [ def:8; ]
       DocType := 4282 string [ range:32..126; ]
       DocTypeVersion := 4287 uint [ def:1; ]
       DocTypeReadVersion := 4285 uint [ def:1; ]
     }
 
     CRC32 := c3 container [ level:1..; card:*; ] {
       %children;
       CRC32Value := 42fe binary [ size:4; ]
     }
     Void  := ec binary [ level:1..; card:*; ]
   }
 
 
Appendix D.  Matroska DTD
 
   declare header {
     DocType := "matroska";
     EBMLVersion := 1;
   }
   define types {
     bool := uint [ range:0..1; ]
     ascii := string [ range:32..126; ]
   }
   define elements {
     Segment := 18538067 container [ card:*; ] {
 
       // Meta Seek Information
       SeekHead := 114d9b74 container [ card:*; ] {
         Seek := 4dbb container [ card:*; ] {
           SeekID := 53ab binary;
           SeekPosition := 53ac uint;
         }
       }
 
       // Segment Information
       Info := 1549a966 container [ card:*; ] {
         SegmentUID := 73a4 binary;
         SegmentFilename := 7384 string;
         PrevUID := 3cb923 binary;
         PrevFilename := 3c83ab string;
         NextUID := 3eb923 binary;
         NextFilename := 3e83bb string;
         TimecodeScale := 2ad7b1 uint [ def:1000000; ]
         Duration := 4489 float [ range:>0.0; ]
         DateUTC := 4461 date;
         Title := 7ba9 string;
         MuxingApp := 4d80 string;
         WritingApp := 5741 string;
       }
 
       // Cluster
       Cluster := 1f43b675 container [ card:*; ] {
         Timecode := e7 uint;
         Position := a7 uint;
         PrevSize := ab uint;
         BlockGroup := a0 container [ card:*; ] {
           Block := a1 binary;
           BlockVirtual := a2 binary;
           BlockAdditions := 75a1 container {
             BlockMore := a6 container [ card:*; ] {
               BlockAddID := ee uint [ range:1..; ]
               BlockAdditional := a5 binary;
             }
           }
           BlockDuration := 9b uint [ def:TrackDuration; ];
           ReferencePriority := fa uint;
           ReferenceBlock := fb int [ card:*; ]
           ReferenceVirtual := fd int;
           CodecState := a4 binary;
           Slices := 8e container [ card:*; ] {
             TimeSlice := e8 container [ card:*; ] {
               LaceNumber := cc uint [ def:0; ]
               FrameNumber := cd uint [ def:0; ]
               BlockAdditionID := cb uint [ def:0; ]
               Delay := ce uint [ def:0; ]
               Duration := cf uint [ def:TrackDuration; ];
             }
           }
         }
       }
 
       // Track
       Tracks := 1654ae6b container [ card:*; ] {
         TrackEntry := ae container [ card:*; ] {
           TrackNumber := d7 uint [ range:1..; ]
           TrackUID := 73c5 uint [ range:1..; ]
           TrackType := 83 uint [ range:1..254; ]
           FlagEnabled := b9 uint [ range:0..1; def:1; ]
           FlagDefault := 88 uint [ range:0..1; def:1; ]
           FlagLacing  := 9c uint [ range:0..1; def:1; ]
           MinCache := 6de7 uint [ def:0; ]
           MaxCache := 6df8 uint;
           DefaultDuration := 23e383 uint [ range:1..; ]
           TrackTimecodeScale := 23314f float [ range:>0.0; def:1.0; ]
           Name := 536e string;
           Language := 22b59c string [ def:"eng"; range:32..126; ]
           CodecID := 86 string [ range:32..126; ];
           CodecPrivate := 63a2 binary;
           CodecName := 258688 string;
           CodecSettings := 3a9697 string;
           CodecInfoURL := 3b4040 string [ card:*; range:32..126; ]
           CodecDownloadURL := 26b240 string [ card:*; range:32..126; ]
           CodecDecodeAll := aa uint [ range:0..1; def:1; ]
           TrackOverlay := 6fab uint;
 
           // Video
           Video := e0 container {
             FlagInterlaced := 9a uint [ range:0..1; def:0; ]
             StereoMode := 53b8 uint [ range:0..3; def:0; ]
             PixelWidth := b0 uint [ range:1..; ]
             PixelHeight := ba uint [ range:1..; ]
             DisplayWidth := 54b0 uint [ def:PixelWidth; ]
             DisplayHeight := 54ba uint [ def:PixelHeight; ]
             DisplayUnit := 54b2 uint [ def:0; ]
             AspectRatioType := 54b3 uint [ def:0; ]
             ColourSpace := 2eb524 binary;
             GammaValue := 2fb523 float [ range:>0.0; ]
           }
 
           // Audio
           Audio := e1 container {
             SamplingFrequency := b5 float [ range:>0.0; def:8000.0; ]
             OutputSamplingFrequency := 78b5 float [ range:>0.0;
                                                     def:8000.0; ]
             Channels := 94 uint [ range:1..; def:1; ]
             ChannelPositions := 7d7b binary;
             BitDepth := 6264 uint [ range:1..; ]
           }
 
           // Content Encoding
           ContentEncodings := 6d80 container {
             ContentEncoding := 6240 container [ card:*; ] {
               ContentEncodingOrder := 5031 uint [ def:0; ]
               ContentEncodingScope := 5032 uint [ range:1..; def:1; ]
               ContentEncodingType := 5033 uint;
               ContentCompression := 5034 container {
                 ContentCompAlgo := 4254 uint [ def:0; ]
                 ContentCompSettings := 4255 binary;
               }
               ContentEncryption := 5035 container {
                 ContentEncAlgo := 47e1 uint [ def:0; ]
                 ContentEncKeyID := 47e2 binary;
                 ContentSignature := 47e3 binary;
                 ContentSigKeyID := 47e4 binary;
                 ContentSigAlgo := 47e5 uint;
                 ContentSigHashAlgo := 47e6 uint;
               }
             }
           }
         }
       }
 
       // Cueing Data
       Cues := 1c53bb6b container {
         CuePoint := bb container [ card:*; ] {
           CueTime := b3 uint;
           CueTrackPositions := b7 container [ card:*; ] {
             CueTrack := f7 uint [ range:1..; ]
             CueClusterPosition := f1 uint;
             CueBlockNumber := 5378 uint [ range:1..; def:1; ]
             CueCodecState := ea uint [ def:0; ]
             CueReference := db container [ card:*; ] {
               CueRefTime := 96 uint;
               CueRefCluster := 97 uint;
               CueRefNumber := 535f uint [ range:1..; def:1; ]
               CueRefCodecState := eb uint [ def:0; ]
             }
           }
         }
       }
 
       // Attachment
       Attachments := 1941a469 container {
         AttachedFile := 61a7 container [ card:*; ] {
           FileDescription := 467e string;
           FileName := 466e string;
           FileMimeType := 4660 string [ range:32..126; ]
           FileData := 465c binary;
           FileUID := 46ae uint;
         }
       }
 
       // Chapters
       Chapters := 1043a770 container {
         EditionEntry := 45b9 container [ card:*; ] {
           ChapterAtom := b6 container [ card:*; ] {
             ChapterUID := 73c4 uint [ range:1..; ]
             ChapterTimeStart := 91 uint;
             ChapterTimeEnd := 92 uint;
             ChapterFlagHidden := 98 uint [ range:0..1; def:0; ]
             ChapterFlagEnabled := 4598 uint [ range:0..1; def:0; ]
             ChapterTrack := 8f container {
               ChapterTrackNumber := 89 uint [ card:*; range:0..1; ]
               ChapterDisplay := 80 container [ card:*; ] {
                 ChapString := 85 string;
                 ChapLanguage := 437c string [ card:*; def:"eng";
                                               range:32..126; ]
                 ChapCountry := 437e string [ card:*; range:32..126; ]
               }
             }
           }
         }
       }
 
       // Tagging
       Tags := 1254c367 container [ card:*; ] {
         Tag := 7373 container [ card:*; ] {
           Targets := 63c0 container {
             TrackUID := 63c5 uint [ card:*; def:0; ]
             ChapterUID := 63c4 uint [ card:*; def:0; ]
             AttachmentUID := 63c6 uint [ card:*; def:0; ]
           }
           SimpleTag := 67c8 container [ card:*; ] {
             TagName := 45a3 string;
             TagString := 4487 string;
             TagBinary := 4485 binary;
           }
         }
       }
     }
   }

Publicación de Anuncios de Juntas Generales Ordinarias en página web

Deja un comentario

Los administradores pueden certificar tranquilamente la publicación ininterrumpida de Anuncios Societarios, tales como los de Convocatoria de Juntas Generales Ordinarias en página web, sabiendo que están respaldados por los sistemas de comprobación fehaciente de EADTrust, European Agency of Digital Trust.

No se la juegue en la organización de las juntas generales, y tenga en cuenta estos servicios especializados, llamando al 917160555.

Cumpliendo perfectamente la Ley de Sociedades de Capital

Cómo debe evolucionar el sector de las mutuas de accidentes de trabajo

Deja un comentario

Este artículo se titulaba originalmente «Urge reinventar el sector«. Su autor es Mariano de Diego Hernández y se publicó el 28 de febrero de 2014 en el web libremercado.com

Es un interesante compendio de las reivindicaciones del sector de las mutuas de accidentes de trabajo, plasmadas por el  presidente de la patronal de mutuas de accidentes de trabajo y enfermedades profesionales (AMAT, Asociación de Mutuas de Accidentes de Trabajo).

AMAT-Mariano-de-DiegoPese a que la situación socioeconómica sigue siendo extremadamente grave y compleja, los resultados del sector de las mutuas de accidentes de trabajo durante el ejercicio 2013 fueron francamente espectaculares. Así, me cabe la satisfacción de manifestar que el pasado ejercicio lo hemos cerrado con un resultado positivo excepcional: hemos generado unos excedentes estimados de más de 1.030 millones de euros; resalto esta impresionante cifra (unos 171.000 millones de las antiguas pesetas).

Estos resultados justifican el que reivindiquemos una vez más la necesidad de que las mutuas recuperemos la disponibilidad sobre los resultados económicos derivados de nuestra gestión, al menos en parte, ya que es el mejor instrumento para perfeccionar la competencia entre las mismas, que debe basarse en la mejora de la calidad y, en su caso, de la cantidad de servicios y prestaciones.

Para primar la gestión de las mutuas que obtienen resultados satisfactorios es necesaria una nueva regulación que permita, por un lado, un retorno a las empresas mutualistas de parte de las primas que han satisfecho en concepto de accidentes de trabajo y, por otro, que parte de los excedentes puedan ser destinados por las mismas, además de a prestar un mejor servicio a los trabajadores protegidos, a mejorar la competitividad mediante una rebaja real y efectiva de las cuotas que satisfacen. El sistema actual, del bonus, no funciona y, sobre la base de la nueva Ley de Mutuas, debe corregirse.

Las mutuas de accidentes de trabajo estamos sometidas a un intervencionismo sin precedentes por parte de la Administración, lo que hace preciso dar un mayor protagonismo a sus órganos de gobierno y propiciar la identificación de los mutualistas con su entidad, conservando ésta su esencia mutualista y su naturaleza de entidad privada con carácter y vocación claramente empresarial». Esta es una realidad que sentimos los empresarios mutualistas.

Los empresarios responsables de las diferentes mutuas de accidentes de trabajo no podemos seguir con esta incierta normativa, que va cercenando paulatinamente nuestra iniciativa.

Estamos intentando consensuar nuestro futuro con el Ministerio de Empleo y Seguridad Social y los agentes sociales, estableciendo unas claras reglas de juego por las que los empresarios asumamos el papel que nos corresponde, de auténticos protagonistas del mutualismo. Este protagonismo hemos de recuperarlo con la mayor urgencia.

Ante la presentación del Anteproyecto de Ley de Mutuas, el pasado mes de diciembre, pienso que ha llegado el momento de que hagamos un alto en el camino, redefiniendo nuevamente el mutualismo, entre la Administración, los agentes sociales (empresarios y sindicatos) y el propio sector.

El complejo mecanismo de sistemas de intervención pública sobre la actuación de las mutuas se ve completado con la existencia deprohibiciones que no tienen sentido, en un marco de libre y leal competencia y de colaboración con la Seguridad Social, como son:

  • La prohibición de hacer publicidad y propaganda competitiva.
  • La prohibición de políticas comerciales de captación.
  • La prohibición de interposición de recursos administrativos, demandas o recursos judiciales de las mutuas con cargo al Presupuesto contra las resoluciones de la Secretaría de Estado de la Seguridad Social, las entidades gestoras o la Tesorería General de la Seguridad Social; deben presentarlos las mutuas con cargo a su propio patrimonio histórico, aunque el beneficio repercuta favorablemente en las cuentas de la Seguridad Social.

Otro exponente claro de la publificación hacia la que se pretende llevar a las mutuas es la asimilación de sus empleados con los funcionarios, anulando la capacidad de las mutuas de desarrollar políticas de recursos humanos propias.

El presupuesto de las mutuas se integra en el de la Seguridad Social y finalmente en los Presupuestos Generales del Estado. En esta materia, también existen destacables restricciones en perjuicio de las mutuas y su buena gestión, viéndose como se ven obligadas a construir presupuestos excesivamente voluntaristas.

Por lo que hace al terreno de la competencia, si algo ha venido caracterizando a las mutuas ha sido el que se ha gestionado la colaboración de prestaciones de Seguridad Social con criterios de empresa privada en un marco competitivo, donde cada mutua ha intentado presentar sus servicios allá donde ha estimado conveniente, con lo que se han generado criterios de eficacia propios de ese margen libre de actuación.

Un nuevo sistema que contemple las propuestas que se vienen señalando y las que más adelante se indican es mejor que el que progresivamente se ha ido implantado, con el que se ha pasado de una gestión privada a una gestión netamente de recursos públicos, con nulo marco de creatividad y un alto coste de oportunidad económico, y donde no se está viendo beneficio vía retorno a quienes los generan: los empresarios.

Asimismo, es evidente que la función de dirección de las mutuas ha tendido hacia una clara dependencia de la norma y de las más diversas formas de dirigir, desde la Administración, que se pueden imaginar. No es posible que se pretenda que la responsabilidad absoluta recaiga sobre los empresarios de las mutuas, y que tengan que estar a las órdenes de la Administración. La nueva ley debe afirmar que la dirección debe corresponder a los órganos de gobierno de las mutuas, en los que están representados todos los empresarios asociados a las mismas.

Los empresarios no queremos que la deriva hacia lo público se siga produciendo. Si se desea continuar con la relación de colaboración de las mutuas con la Seguridad Social, tiene que garantizarse su forma de gestión privada, para lo que resulta necesario una modificación del marco normativo de las mutuas, contrario del que aparece en el anteproyecto de ley.

El principio alrededor del cual planteamos reformar la colaboración en la gestión de las mutuas es la congruencia de su naturaleza privada con una gestión privada efectiva. Esa naturaleza privada debe verse reforzada dotando a las mutuas de la suficiente capacidad de gobierno y de gestión.

En tal sentido, y como responsables de las mutuas, las juntas directivas de las mismas hemos definido unos puntos que entendemos deberían orientar la reforma de la colaboración de las mutuas en la nueva ley:

  • Plena autonomía de gestión.
  • Libertad de elección, alternatividad o voluntariedad de aseguramiento.
  • Propiedad de los beneficios. Una vez dotadas las provisiones y reservas obligatorias y estatutarias, el destino que en cada caso debería darse a los beneficios de las mutuas sería el que se decidiese en sus juntas generales, pudiendo retornar parte a los empresarios asociados y a las propias mutuas, sin perjuicio de que se fijen las aportaciones a la Seguridad Social que correspondan.
  • Libre competencia. Los beneficiarios siempre serían la Seguridad Social, las empresas y los trabajadores.
  • Seguimiento de la incapacidad temporal derivada de contingencias comunes, con la posibilidad de dar altas (es la única forma de intentar atajar el cáncer del absentismo en nuestras empresas).

Los empresarios que formamos parte de los órganos de gobierno de las mutuas observamos que subsisten importantes restricciones que obstaculizan la gestión de nuestras entidades.

Si ni las primas recaudadas ni los excedentes de la gestión son recursos privativos de los empresarios asociados, sino recursos públicos, poco interés puede haber en lograr una gestión eficiente, más allá de tratar de asegurar los ingresos necesarios para cubrir los compromisos de gasto adquiridos y evitar que pueda hacerse efectiva la responsabilidad de los empresarios asociados.

Muchas de estas restricciones a la libre actuación de las mutuasencuentran su justificación en la naturaleza de los recursos que se gestionan; precisamente, para evitar un uso indebido de los recursos públicos se somete a las mutuas a los mismos controles exhaustivos previstos para todo el sector público en materia de contratación y fiscalización, por ejemplo.

Por ello, resulta del todo desmesurado que, a través del nuevo marco normativo en tramitación, se pretenda someter a las mutuas a controles mayores incluso a los actualmente vigentes para las entidades públicas, cuando al fin y al cabo las mutuas son entidades privadas. Obviamente, entendemos que esto no es proporcionado ni tiene razón de ser, puesto que las medidas de control introducidas en la normativa actual son más que suficientes para garantizar el buen uso de los recursos públicos. Establecer más medidas de control terminaría por lastrar la actuación de las mutuas, cuando lo que realmente resulta necesario es que estos controles sean los mínimos, efectivos y con la máxima seguridad jurídica.

No existe otro medio de alinear incentivos y, a la vez, evitar un uso indebido de recursos públicos que devolver a las empresas mutualistas y a las propias mutuas parte de los recursos que gestionan, y es en este sentido en el que planteamos esta reforma.

No me cansaré de reiterar que es necesaria una nueva regulación que suponga, por un lado, un retorno a los mutualistas de parte de las primas que hemos satisfecho en concepto de accidentes de trabajo y, por otro, permitir que parte de los excedentes puedan ser destinados por las mutuas no sólo a prestar un mejor servicio a los trabajadores protegidos, sino a las propias empresas mutualistas, lo que supondrá una rebaja real y efectiva de las cuotas que satisfacemos los empresarios.

Esperemos que la urgente tarea de la refundación de las mutuasconforme a las líneas antes expuestas se haga con la mayor seriedad, atendiendo las continuas reclamaciones y sugerencias realizadas por nuestro sector.

EN 319 162 Associated Signature Containers (ASiC)

Deja un comentario

La norma TS 102 918 ahora pasa a denominarse EN 319 162 tras la armonización normativa propiciada por el Mandato 460.

El comercio electrónico se está convirtiendo en la forma en la que tendrán lugar en el futuro de los negocios entre las empresas a través de área local, amplia y redes globales. La confianza en esta forma de hacer negocios es esencial para el éxito y el desarrollo continuo del comercio electrónico .

Por tanto, es importante que las empresas que utilizan este medio electrónico en su actividad empresarial tengan controles de seguridad adecuados y mecanismos para proteger sus transacciones y garantizar la confianza  con sus socios comerciales. En este sentido, la firma electrónica es un componente de seguridad importante que se puede utilizar para proteger la información y proporcionar la confianza en el comercio electrónico y en las gestiones con las administraciones públicas.

La Directiva Europea sobre un marco comunitario para la firma electrónica [ i.3 ] define la firma electrónica como : «Los datos en formato electrónico que se adjuntan o se asocian lógicamente a otros datos electrónicos y que sirve como Método de autenticación «.

Las normas EN 319 122-1  ( CAdES ) y EN 319 132-1  ( XAdES ) definen formatos para la firma electrónica en línea con esta definición . Estos formatos incluyen modos de uso mediante los cuales la firma se disocia de los datos a los que se aplica. La norma EN 319 162 especifica el uso de estructuras de contenedores para vincular firmas disociadas («detached»), tanto Firmas CAdES como firmas XAdES  o  sellos de tiempo (RFC 3161), con uno o más objetos firmados a de los que se derivan las firmas.

Conviene recordar la denominación anterior de estas normas:

  • CAdES: EN 319 122 anteriormente TS 101 733. Firmas electrónicas avanzadas usando sintaxis ASN.1 y basado en el formato CMS
  • XAdES: EN 319 132 anteriormente TS 101 903, Firmas electrónicas avanzadas usando sintaxis y formato XML

Ojo. Las facturas rectificativas se deben notificar de forma fehaciente

Deja un comentario

Esta recomendación es específicamente para la recuperación de IVA de las facturas que se puedan considerar incobrables.

El articulo 80 de la Ley de IVA permite la rectificación de las facturas emitidas en ciertos supuestos: cuando los créditos pueden considerarse incobrables, en el caso de concurso de acreedores del deudor o después de haberse instado el cobro judicial o por requerimiento notarial.

El Real Decreto 828/2013, de 25 de octubre modifica, entre otros, el artículo 24 del Reglamento del IVA, en lo relativo a la expedición y remisión de las facturas rectificativas, en el sentido ya definido por la Resolución nº 00/1582/2007 de Tribunal Económico-Administrativo Central (TEAC), 9 de Junio de 2009

El apartado 1 del artículo 24 queda redactado como sigue:

«En los casos a que se refiere el artículo 80 de la Ley del Impuesto, el sujeto pasivo estará obligado a expedir y remitir al destinatario de las operaciones una nueva factura en la que se rectifique o, en su caso, se anule la cuota repercutida, en la forma prevista en el artículo 15 del Reglamento por el que se regulan las obligaciones de facturación, aprobado por el Real Decreto 1619/2012, de 30 de noviembre. En los supuestos del apartado tres del artículo 80 de la Ley del Impuesto, deberá expedirse y remitirse asimismo una copia de dicha factura a la administración concursal y en el mismo plazo.

La disminución de la base imponible o, en su caso, el aumento de las cuotas que deba deducir el destinatario de la operación estarán condicionadas a la expedición y remisión de la factura que rectifique a la anteriormente expedida, debiendo acreditar el sujeto pasivo dicha remisión.” 

La norma insiste sobre la obligación de acreditar la remisión de la factura rectificativa. Para ello, una forma de remitirla será mediante sistemas de comunicación fehaciente como Noticeman. Llame al 902 365 612 para más información.

Sin la acreditación fehaciente de la remisión de la factura, Hacienda no permitirá la recuperación de la cuota de IVA repercutido.

El Corte Inglés incorpora el contact less NFC de Visa en todos sus centros

Deja un comentario

Ya se han instalado 5.200 nuevos terminales específicos para pagar sin contacto, lo que supone el 25% de los terminales.

La cadena de grandes almacenes El Corte Inglés ha recibido la certificación de Visa Europe para la implantación de los pagos sin contacto NFC en toda su red comercial, de forma que a partir de ahora los clientes pueden pagar con las tarjetas o pegatinas contact less o a través de los móviles smartphone que tengan equipado NFC.

Para ello, El Corte Inglés ha instalado más de 5.200 nuevos terminales que incorporan esta tecnología en todos sus centros, lo que representa el 25% del total de los terminales y se espera que a finales de este año 2014, se alcance más de un 60%.

Para la compañía de medios de pago la previsión es que se vaya incrementando progresivamente el número de terminales a medida que se generalice su uso.

La tecnología contactless («sin contactos») permite realizar pagos rápidos y seguros, con sólo aproximar la tarjeta de crédito (que incluya esta tecnología) o el móvil NFC (que se haya configurado adecuadamente, registrando los números de tarjeta a través de las que se desea canalizar las operaciones de pago) a pocos centímetros, entre 3 y 5, del terminal y sin necesidad de teclear el PIN en transacciones de bajo importe. Solo si el importe de la transacción es superior a 20 euros, el cliente deberá introducir su PIN en el terminal.

Luis-Visa-El-Corte-Ingles
Visa Europe ha dado los últimos datos sobre estos pagos indicando que durante el pasado mes de noviembre de 2013 en España se contabilizaron 2,1 millones de transacciones sin contacto con tarjetas Visa (+397% sobre el mismo periodo del año anterior), que generaron un gasto en comercios de 67,2 millones de euros, un 369% más que en noviembre de 2012.

En estas fechas existen en España más de 347.000 terminales punto de venta adaptados a esta tecnología de pago y se espera que a finales de 2014 se alcance más del 50% de penetración en comercios y grandes superficies. En cuanto a tarjetas Visa contactless, se superó la cifra de 5 millones de unidades, lo que supone un incremento del 234% sobre el mismo mes del año anterior. Se estima que para finales del 2014 Visa alcance los 10 millones de tarjetas sin contacto en España.

Para El Corte Inglés esta iniciativa se enmarca en su orientación comercial siempre a la vanguardia de la tecnología dando respuesta a las nuevas necesidades y demandas de la sociedad y de sus clientes.

“Visa Europe ha apostado desde hace años por la tecnología NFC. A día de hoy, no sólo Visa, sino las operadoras de telefonía y la mayoría de los fabricantes de móviles están apostando también fuertemente por esta tecnología. Es muy importante que grandes grupos del sector de la distribución como El Corte Inglés apuesten también por la innovación en las tecnologías de pago, de forma que sus clientes puedan beneficiarse de la comodidad, rapidez y seguridad que les van a aportar los pagos sin contacto”, ha comentado Luis García Cristóbal, director general de Visa Europe para España y Portugal.

 

Reached Member States’ endorsement of a final draft regulation on electronic identification and trust services for electronic transactions in the internal market

Deja un comentario

Vice-President Neelie Kroes and Commissioner Michel Barnier welcomed last friday (February, the 28th) Member States’ endorsement of a “Draft regulation on electronic identification and trust services for electronic transactions” in the internal market.

The Regulation will enable, for example, students to enrol at a foreign university online; citizens to fill on-line tax returns in another EU country; and businesses to participate electronically in public calls for tenders across the EU, to mention just a few of multiple new digital trust related services.

Neelie Kroes said: «The adoption of this Regulation on e-ID is a fundamental step towards the completion of the Digital Single Market. This agreement boost trust and convenience in cross-border and cross-sector electronic transactions. I would like to thank the European Parliament, especially ITRE’s rapporteur, Marita Ulvskog and IMCO’s rapporteur, Marielle Gallo, the shadow rapporteurs, as well as the Greek, Lithuanian, Irish and Cypriot Presidencies for all their work on this file.»

Last friday (February, the 28th), EU ambassadors endorsed the political agreement reached between representatives of the European Parliament, Commission and Council on Tuesday 25 February on the final elements of this significant single market proposal.

A predictable regulatory environment for eID and electronic trust services is key to promote innovation and stimulate competition. On the one hand, it will ensure that people and businesses can use and leverage across borders their national eIDs to access at least public services in other EU countries fully respecting privacy and data protection rules. On the other hand, it will remove the barriers to seamless electronic trust services across borders by ensuring that they enjoy the same legal value as in paper-based processes.

Michel Barnier, Commissioner for Internal Market and Services added:

«I welcome this agreement which is key to completing our work on the Single Market Act. It is an important step for the development of e-commerce, e-invoicing and e-procurement. The new rules will allow all actors in the single market – citizens, consumers, businesses and administrative authorities – to develop their «on-line» activities.»

Background regarding draft Regulation on electronic identification and trust services for electronic transactions

On 4 June 2012, the European Commission proposed a draft Regulation on electronic identification and trust services for electronic transactions in the internal market (see IP/12/558 and MEMO/12/403)

The Regulation is due to be formally endorsed by the European Parliament in the April 2014 plenary session and by the Council of Ministers in June. It will come into force on 1st July 2014 and will be directly applicable cross the EU from that date. The economic effect will be immediate, overcoming problems of fragmented national legal regimes and cutting red tape and unnecessary costs.

Foster the interoperability of eID usage and trust services. The existing EU legislation on eSignatures has been strengthened and extended to cover the full set of electronic identification and trust services and make it more fit for the digital single market. This will have a huge impact on the legal validity and interoperability of national and cross-border electronic transactions.

The so named eIDAS Regulation provides for principles, like:

  • Transparency and accountability: well-defined minimal obligations for Trust Services Providers (TSPs) and liability;
  • Trustworthiness of the services together with security requirements for TSPs
  • Technological neutrality: avoiding requirements which could only be met by a specific technology;
  • Market rules and building on standardisation

And defines digital trust related services such as:

  • Electronic identification,
  • Electronic signatures,
  • Electronic seals,
  • Time stamping,
  • Electronic delivery service,
  • Electronic documents admissibility,
  • Website authentication

After eIDAS entering into force,  a EU Member State:

  • May ‘notify’ the ‘national’ electronic identification scheme(s) used at home for access to its public services
  • Must recognise ‘notified’ eIDs of other Member States for cross-border access to its online services when its national laws mandate e-identification
  • Must provide a free online authentication facility for its ‘notified’ eID(s)
  • Is liable for unambiguous identification of persons and for authentication;

ETSI TR 119 000: “Rationalised Framework for Electronic Signature Standardisation”

Deja un comentario

Merece la pena echar un vistazo al informe técnico TR 119 000 porque describe la estructura completa del nuevo conjunto de estándares aplicables a la firma electrónica, a partir del esfuerzo de Mandato M460, desarrollado en paralelo con la gestión de aprobación del nuevo reglamento europeo de firma electrónica: REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on electronic identification and trust services for electronic transactions in the internal market

(se incluye un resumen amplio a continuación, con algunos fallos de formato que iré corrigiendo con el tiempo)

As a response to the adoption of Directive 1999/93/EC [i.1] on a Community framework for electronic signatures in 1999, and in order to facilitate the use and the interoperability of eSignature based solution, the European Electronic Signature Standardization Initiative (EESSI) was set up to coordinate the European standardization organisations CEN and ETSI in developing a number of standards for eSignature products.

Commission Decision 2003/511/EC [i.2], on generally recognised standards for electronic signature products, was adopted by the Commission following the results of the EESSI. This decision fostered the use of eSignature by publishing «generally recognised standards» for electronic signature products in compliance with article 3(5) of the Directive but has a limited impact on the mapping of the current state of the European standardisation on eSignatures, which also covers ancillary services to eSignature, and the legal provisions and requirements laid down in Directive 1999/93/EC [i.1].

Emerging cross-border use of eSignatures and the increasing use of several market instruments (e.g. Services Directive [i.3], Public Procurement [i.4] and [i.5], eInvoicing [i.6]) that rely in their functioning on eSignatures and the framework set by the Signature Directive emphasized problems with the mutual recognition and cross-border interoperability of eSignature.

Intending to address the legal, technical and standardisation related causes of these problems, the Commission launched a study on the standardisation aspects of eSignature [i.7] which concluded that the multiplicity of standardization deliverables together with the lack of usage guidelines, the difficulty of access and lack of business orientation is detrimental to the interoperability of eSignature, and formulated a number of recommendations to mitigate this. Also due to the fact that many of the documents have yet to be progressed to full European Norms (ENs), their status may be considered to be uncertain. The Commission also launched the CROBIES study [i.8] to investigate solutions addressing some specific issues regarding profiles of secure signature creation devices, supervision practices as well as common formats for trusted lists, qualified certificates and signatures.

In line with Standardisation Mandate 460 [i.9], consequently issued by the Commission to CEN, CENELEC and ETSI for updating the existing eSignature standardisation deliverables, CEN and ETSI have set up the eSignature Coordination Group in order to coordinate the activities achieved for Mandate 460. One of the first tasks in the current document establishes a rationalised framework to overcome these issues within the context of the Signature Directive, taking into account possible revisions to this Directive, and proposes a future work programme to address any elements identified as missing in this rationalise framework. The following web site was set up in the framework in Mandate 460: http://www.e-signatures-standards.eu/.

In June 2012, the European Commission has issued a proposal for a regulation on electronic identification and trust services for electronic transactions in the internal market [i.22] which is aimed to supersede the Directive 1999/93/EC [i.1]. This brings within the scope of regulation additional services for identification and as authentication alongside electronic signatures and defines additional forms of qualified certificates.

The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.
[i.1]  Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures.
[i.2]  Commission Decision 2003/511/EC of 14.7.2003 on the publication of reference numbers of generally recognised standards for electronic signature products in accordance with Directive 1999/93/EC of the European Parliament and of the Council.
[i.3]  Directive 1998/34/EC of the European Parliament and the Council of 22.6.1998 laying down a procedure for the provision of information in the field of technical standards and regulations and of rules on Information Society services.
[i.4]  Directive 2004/18/EC of the European Parliament and Council of 31.3.04 on the coordination of procedures for the award of public works contracts, public supply contracts and public service contracts.
[i.5]  Directive 2004/17/EC of the European Parliament and Council of 31.3.04 coordinating the procurement procedures of entities operating in the water, energy, transport and postal services sectors.
[i.6]  Council Directive 2006/112/EC of 28.11.06 on the common system of value added tax.
[i.7]  «Study on the standardisation aspects of e-signatures», SEALED, DLA Piper et al, 2007. NOTE: Available at:

Haz clic para acceder a report_esign_standard.pdf

[i.8]  «CROBIES: Study onCross-Border Interoperability of eSignatures», Siemens, SEALED and TimeLex, 2010. NOTE: Available at: http://ec.europa.eu/information_society/policy/esignature/crobies_study/index_en.htm

[i.9]  Mandate M460: «Standardisation Mandate to the European Standardisation Organisations CEN, CENELEC and ETSI in the Field of Information and Communication Technologies Applied to Electronic Signatures».
[i.10]  ISO/IEC 27000: «Information technology — Security techniques — Information security management systems — Overview and vocabulary».
[i.11]  IETF RFC 3647: «Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework».
[i.12]  W3C Recommendation: «XML Signature Syntax and Processing (Second Edition)», 10 June 2008.
[i.13]  ISO 32000-1: «Document management — Portable document format — Part 1: PDF 1.7».
[i.14]  Commission Decision 2011/130/EU of 25 February 2011 establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market.
[i.15]  Directive 2006/123/EC of the European Parliament and of the Council of 12 December 2006 on services in the internal market.
[i.16]  IETF RFC 3161 (August 2001): «Internet X.509 Public Key Infrastructure Time-Stamp Protocol».
[i.17]  CCMB-2006-09-001: «Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model; Version 3.1, Revision 3», July 2009.
[i.18]  ITU-T Recommendation X.509/ISO/IEC 9594-8: «Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks».
[i.19]  Commission Decision 2009/767/EC of 16 October 2009 setting out measures facilitating the use of procedures by electronic means through the ‘points of single contact’ under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market.
[i.20]  Commission Decision 2010/425/EU of 28 July 2010 amending Decision 2009/767/EC as regards the establishment, maintenance and publication of trusted lists of certification service providers supervised/accredited by Member States.
[i.21]  ITU-T Recommendation X.1254/ISO/IEC DIS 29115: «Information technology – Security techniques – Entity authentication assurance framework».
[i.22]  Brussels, 4.6.2012 COM(2012) 238 final, Proposal for a regulation of the european parliament and of the council on electronic identification and trust services for electronic transactions in the internal market.
[i.23]  ETSI TR 119 001:» Rationalised Framework for Electronic Signature Standardisation: Definitions and abbreviations.»

Definitions

  • advanced electronic signature: electronic signature which meets the following requirements:

a)  it is uniquely linked to the signatory;
b)  it is capable of identifying the signatory;
c)  it is created using means that the signatory can maintain under his sole control; and
d)  it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable.

  • certificate: electronic attestation which links signature verification data to an entity or a legal or natural person and confirms the identity of that entity or legal or natural person
  • certification service provider: entity or legal or natural person who issues certificates or provides other servicesrelated to electronic signatures
  • certificate validation:process of checking that a certificate or certificate path is validelectronic signature (eSignature): data in electronic form which are attachedto or logically associated with other electronic data and which serve as a method of authentication
  • qualified certificate: certificate which meets the requirements laid down in Annex I of Directive 1999/93/EC [i.1] andis provided by a certification service provider who fulfils the requirements laid down in Annex II of Directive1999/93/EC [i.1]
  • qualified electronic signature:advanced electronic signature which is based on a qualified certificate and which is created by a secure signature creation device
  • secure signature creation device:signature creation device which meets the requirements laid down in Annex III of Directive 1999/93/EC [i.1]
  • signatory:person who holds a signature creation device and acts either on his own behalf or on behalf of the natural orlegal person or entity he represents
  • signature creation data:unique data, such as codes or private cryptographic keys, which are used by the signatory tocreate an electronic signature
  • signature creation device:configured software or hardware used to implement the signature-creation data signature validation:process of checking that a signature is valid including overall checks of the signature againstlocal or shared signature policy requirements as well as certificate validation and signature (cryptographic) verification
  • signature verification:process of checking the cryptographic value of a signature using signature verification data signature verification data:data, such as codes or public cryptographic keys, which are used for the purpose of verifying an electronic signature
  • signature verification device:configured software or hardware used toimplement the signature-verification data
  • Data Preservation Service Provider (DPSP):Trust Application Service Provider which provides Trust Services towhich data, among which documents, is entrusted in an agreed form (digital or analogue) for being securely kept indigital form for a period of time specified in the applicable agreement .NOTE:  This service is expected to be able to exhibit all preserved data at any moment during, or at the end of, thepreservation period.
  • registered e-mail:enhanced form of mail transmitted by electronic means (e-mail) which provides evidence relating to the handling of an e-mail including proof of submission and delivery
  • registered electronic delivery: enhanced form of electronic delivery which provides evidence of relating to the handling of electronic messages including proof of submission and delivery
  • registered electronic delivery service provider:trust application service provider which provides registered electronicdelivery trust services
  • registered e-mail service provider:trust application service provider which provides registered e-mail trust services signature generationservice provider:trust service provider which provides trust services that allow secure remotemanagement of signatory’s signature creation device and generation of electronic signatures by means of such a remotely managed device
  • signature policy: set of rules for the creation and validation of one (or more interrelated) electronic signature(s) that defines the technical and procedural requirements for creation, validation and (long term) management of this (those) electronic signature(s), in order to meet a particular business need, and under which the signature(s) can be determined to be valid.

NOTE 1: When validated against a signature policy X, the validity of an electronic signature is a relative concept and will be determined against the rules defined by such a policy. The same signature can be determined as valid against signature policy X while being invalid against signature policy Y. The notion of Signature Policy here should be clearly dissociated from a legal purpose document. While the Signature Policy is expected to further precise the context in which the underlying signatures are to be considered as valid in a specific context (e.g. business process, a specific application), their potential legal effect and value will be driven by the applicable laws and/or contractual relationships between the parties involved and concerned by the signatures. Closed user group domains of application should be clearly distinguished from a purely open context to which generally applicable laws may address.

NOTE 2:  A Signature Policy covers the three following aspects related to the management of each of the considered electronic signature(s):

1.  a Signature Creation Policy: part of the Signature Policy, which specifies the technical and procedural requirements onthe signer in creating a signature;
2.  a Signature Validation Policy: part of the Signature Policy, which specifies the technical and procedural requirements on the verifier when validating a signature; and
3.  a Signature (LTV) Management Policy: part of the Signature Policy, which specifies the technical and procedural requirements on the long term management and preservation of a signature.

  • signature validation service provider: trust service provider offering services in relation to validation of Electronic Signatures
  • time-stamping service provider: trust service provider which issues time-stamp tokens. NOTE:  This entity may also be referred to as a Time-Stamping Authority.
  • time-stamp token:data object that binds a representation of a datum to a particular time, thus establishing evidence that the datum existed before that time
  • trust application service provider: trust service provider operating a value added Trust Service based on Electronic Signatures that satisfies a business requirement that relies on the generation/verification of Electronic Signatures in its daily routine. NOTE:  This covers namely services like registered electronic mail and other type of e-delivery services, as well as long term storage services related to signed data and Electronic Signatures.
  • trust service:electronic service which enhances trust and confidence in electronic transaction. NOTE:  Such Trust Services are typically but not necessarily using cryptographic techniques or involving confidential material.
  • trust service provider:entity which provides one or more electronic Trust Service. NOTE:  See annex A for discussion on certification service provider and Trust Service Provider.
  • trust service status list:list of the trust service status information, protected to assure its authenticity and integrity, from which interested parties may determine whether a trust service has been assessed as operating in conformity with recognised criteria for a given class of trust service
  • trust service status list provider:trust service provider issuing a Trust Service Status List
  • trust service token:physical or binary (logical) object generated or issued as a result of the use of a Trust Servic. NOTE:  Examples of binary Trust Service Tokens are certificates, CRLs, Time-Stamp Tokens, OCSP responses, evidence of delivery issued by a REM Service Provider.
  • trusted list:profile of the trust service status list that is the national supervision/accreditation status list of certification services from Certification Service Providers, which are supervised/accredited by the referenced Member State for compliance with the relevant provisions laid down in Directive 1999/93/EC [i.1]

Abbreviations

  • AdES  Advanced Electronic Signature
  • AdESQC
    Advanced Electronic Signature supported by a Qualified Certificate  ANSSI  (French) Agence national de la Sécurité de Systèmes d’Information
  • API  Application Program Interface
  • ASiC  Associated Signature Containers
  • BES  Basic Electronic Signature (used with CAdES/XAdES and PAdES)
  • BSI  Bundesamt für Sichereit (German Federal Office for Information Security)
  • CA Certification Authority
  • CAB Forum  CA Browser Forum
  • CAdES  CMS Advanced Electronic Signature
  • CD  [European] Commission Decision
  • CEN  Comité Européen de Normalisation
  • CMS  Cryptographic Message Syntax
  • CRL Certificate Revocation List
  • CSP  Certification Service Provider
  • CWA CEN Workshop Agreement
  • DIS Draft International Standard
  • DPS  Data Preservation System
  • DPSP  Data Preservation Service Provider
  • DSS  Digital Signature Standard (as published by OASIS)
  • E-CODEX  e-Justice Communication via Online Data Exchange
  • EESSI  European Electronic Signature Standardization Initiative
  • EN European Norm
  • EPES  Explicit Policy Electronic Signature (used with CAdES / XAdES and PAdES)
  • ETSI  European Telecommunications Standards Institute
  • HSM  Hardware Security Module
  • HTTP  Hypertext Transfer Protocol
  • IAS  Identification, Authentication and Digital Signature
  • IDPF  International Digital Publishing Forum
  • ISO  International Organization for Standardization
  • LoA  Level of Assurance
  • LTV  Long term Validation (used with PAdES)
  • MTM Mobile Trusted Module
  • NFC  Near Field Communication
  • OCSP  Online Certificate Status Protocol
  • OASIS  Organization for the Advancement of Structured Information Standards
  • OEBPS  Open E-Book Publishing Structure
  • PAdES  PDF Advanced Electronic Signature
  • PKC  Public Key Certificate
  • PEPPOL  Pan-European Public eProcurement On-Line
  • PP Protection Profile
  • QC Qualified Certificate
  • QES  Qualified Electronic Signature
  • RED  Registered Electronic Delivery
  • REM  Registered Electronic Mail
  • REM-MD  Registered Electronic Mail – Management Domain
  • SCA Signature Creation Application
  • SGSP  Signature Generation Service Provider
  • SOGIS  Senior Officials Group – Information Systems Security
  • SP Signature Policy
  • SR Special Report
  • SCD  Signature Creation Device
  • SSCD  Secure Signature Creation Device
  • SMIME  Secure Multi-Purpose Internet Mail Extensions
  • SMTP  Simple Mail Transfer Protocol
  • SOAP  Simple Object Access Protocol
  • SPOCS  Simple Procedures Online for Cross-border Services
  • STORK  Secure identity across borders linked) being the most relevant
  • SSL Secure Socket Layer
  • SVA Signature Validation Application
  • SVSP  Signature Validation Service Provider
  • TASP  Trust Application Service Provider
  • TC Technical Committee
  • TOE  Target of Evaluation
  • TEE  Trusted Execution Environment
  • TL Trusted List
  • TR Technical Report
  • TS Technical Specification
  • TSL  Trust Service Status List
  • TSP  Trust Service Provider
  • TSPPKC  Trust Service Provider issuing Public Key Certificates
  • TSPQC  Trust Service Provider issuing Qualified Certificates
  • TSSLP  Trust Service Status List Provider
  • TSSP  Time-Stamping Service Provider
  • UPU  Universal Postal Union
  • USB  Universal Serial Bus
  • WI Work Item
  • XAdES  XML Advanced Electronic Signature
  • XSL eXtensible Stylesheet Language
  • XML eXtensible Markup Language
  • XMLDSig  XML Digital Signature

Document Types

The documents required for standardisation of each of the different electronic signature functional areas have been  organised around the following five types of documents:

  1. Guidance:This type of documents does not include any normative requirements but provides business driven guidance on addressing the eSignature (functional) area, on the selection of applicable standards and their options for a particular business implementation context and associated business requirements, on the implementation of a standard (or a series of standards), on the assessment of a business implementation against  a standard (or a series of standards), etc.
  2. Policy & Security Requirements:This type of document specifies policy and security requirements for  services and systems, including protection profiles. This brings together use of other technical standards and  the security, physical, procedural and personnel requirements for systems implementing those technical  standards.
  3. Technical Specifications:This type of document specifies technical requirements on systems. This includes  but is not restricted to technical architectures (describing standardised elements for a system and their  interrelationships), formats, protocols, algorithms, APIs, profiles of specific standards, etc.
  4. Conformity Assessment:This type of document addresses requirements for assessing the conformity of a  system claiming conformity to a specific set of technical specifications, policy or security requirements  (including protection profiles when applicable). This primarily includes conformity assessment rules (e.g.  common criteria evaluation of products or assessment of systems and services).
  5. Testing Compliance & Interoperability:This type of document addresses requirements and specifications  for setting-up interoperability tests or testing systems or for setting-up tests or testing systems that will provide  automated checks of compliance of products, services or systems with specific set(s) of technical specifications.

Numbering Scheme

A consistent numbering for such documentation was searched with the aim to identify a single and consistent series of  eSignature standards and with the aim to enable each document to keep the same number whatever maturity level it  reaches through its lifetime. The numbering scheme being used is defined as follows:

  • DD L19 xxx-z

Where:

  • DD  indicates the deliverable type in the standardisation process (SR, TS, TR and EN)
  • L
    when set to 4: identifies a CEN deliverable,
    when set to 0, 1, 2, or 3: identifies an ETSI deliverable and the type of deliverable in the  standardisation process

019 for ETSI published Special Reports (SR)
119 for ETSI published Technical Specification (TS) and Technical Report (TR)
219 for ETSI published Standard (ES) and ETSI Guide (EG)
319 for ETSI published European Norm (EN)
419 for CEN published Technical Specification (TS) or European Norm (EN)

  • 19  indicates the series of standardisation documents related to eSignatures
    ETSI/CEN may further extend this numbering system in line with their own practices.
  • xxx  indicates the serial number (000 to 999):

where Xxx identifies the area:

0-generic to a number of areas;
1-Signature Creation and Validation;
2-Signature Creation Devices;
3-cryptographic suites;
4-Trust Service Providers  supporting eSignatures;
5-Trust Application Service Providers;
6-Trust Service Status Lists Providers);

where xXx identifies a sub-area within the identified area, or 0 for documents generic to a given area;
where xxX identifies the type of document:

0-Guidance;
1-Policy and Security Requirements;
2-Technical Specifications;
3-Conformity Assessment;
4- Testing Compliance and Interoperability.

  • -z  identifies multi-parts as some documents may be multi-part documents.

Additional numbering for identifying parts and versions will be in line with ETSI or CEN conventions depending on which organisation publishes the document.

Defined documents: Generic

Guidance

TR 119 000  Rationalised structure for Electronic Signature Standardisation
This document provides the framework for the x19 000 series of documents on Electronic Signature standardisation. It  specifies the schema for electronic signature standardisation. It also provides the basis for the provision of business guidance provided in the other areas and reference the business guidance for signature creation and validation (TR 119  100) as the recommended starting point for the analysis of requirements in particular for those target audiences being  stakeholders wishing to introduce and implement eSignatures in a business electronic process. It includes a basic  classification on assurance levels to be used across all the areas. In addition, it establishes definitions of commonly  applicable terms.
TR 419 010  Extended Rationalised structure including IAS
This document proposes an extension for the Rationalised structure for Electronic Signature Standardisation to cover  Electronic Identification, Authentication and Signatures.
SR 019 020  Rationalised Framework of Standards for AdES in Mobile environments
This document will provide details on the framework of standards (including potential architectures and relevant  scenarios) required for the creation and validation of advanced electronic signatures in the mobile environment  (Advanced Electronic Signatures in Mobile Environments).

Policies

TR 119 001  Rationalised Framework for Electronic Signature Standardisation: Definitions and  abbreviations
This document will list all definitions & abbreviations used in documents of the rationalised framework and serve as  reference. Documents from the rationalised framework will either include definitions / abbreviations by reference to TR  119 001 and/or by copying definitions from TR 119 001.

Defined documents: Signature generation and validation

Guidance

EN 319 142  PDF Advanced Electronic Signatures (PAdES)

This multipart document contains all the specifications related to Advanced Electronic Signatures embedded within PDF documents. It includes the base specification and associated profiles, and in particular.

  • PAdES Overview – a framework document for PAdES:This document provides a framework for the set of profiles for PAdES. It provides a general description of support for signatures in PDF documents including use of XML signatures to protect XML data in PDF documents; it also lists the features of the different profiles specified in other parts of the document; finally it describes how the profiles may be used in combination.
  • PAdES Basic – Profile based on ISO 32000-1: This document profiles the use of PDF signatures, based on CMS, as described in ISO 32000-1, for its use in any application areas where PDF is the
    appropriate technology for exchangeof digital documents including interactive forms.
  • PAdES Enhanced – PAdES-BES and PAdES-EPES Profiles:This document profiles the use of PDF Signatures specified in ISO 32000-1 with an alternative signature encoding to support signature formats equivalentto the signature forms CAdES-BES, CAdES-EPES and CAdES-T as specified in EN 319 122.
  • PAdES Long Term – PAdES-LTV Profile:This document profiles the electronic signature formats found in ISO 32000-1 to support Long Term Validation (LTV) of PDF signatures. It specifies a profile to support the equivalent functionality to the signature forms CAdES-X Long and CAdES-A as specified in EN 319 122 in a single profile PAdES-LTV, by incorporation ofnewly specified PDF objects conveying the required validation material.
    PAdES for XML Content – Profiles for XAdES signatures:This document defines profiles for the usage of XAdES signatures, as defined in EN 319 132, for signing XML content within the PDF containers, including the following situations:

    • One XML document (compliant with an arbitrary XML language, like Universal Business Language for e-Invoicing) that is completely or partially signed with at least one enveloped XAdES signature and that is incorporated within a PDF container.
    • Signed (with XML Sig or XAdES signature) dynamic XML Forms Architecture forms.
  • Visual Representations ofElectronic Signatures:This document specifies requirements and recommendations for the visual representations of Advanced Electronic Signatures (AdES) in PDFs. This covers:
    • Signature appearance: The visual representation of the human act of signing placed within a PDF document at signing time and linked to an Advanced Electronic Signature.
    • Signature validation representation: The visual representation of the validation of an Advanced Electronic Signature.
  • PAdES Baseline Profile:This document specifies a profile identifying a common set of options that are appropriate for maximizing interoperability between PAdES signatures.

NOTE 1:  The baseline profile defines a baseline profile for PAdES that provides the basic features necessary for a wide range of business and governmental use cases for electronic procedures and communications to be applicable to a wide range of communities when there is a clear need for interoperability of AdES signatures to be interchanged across borders. In particular it takes into account needs for interoperability of AdES signatures used in electronic documents issued by competent authorities to be interchanged across borders in the context of the EU Services Directive.
NOTE 2: When no specific use case would have requirements not satisfied by the baseline profile, no other specific profile will be added. Should it be otherwise, new profiles would be build on the baseline profile, unless the actual requirements would avoid it.
TS 119 152  Architecture for Advanced Electronic Signatures in Mobile Environments
This document will identifies the architectural components, protocol requirements and sequence of interactions required for scenarios based on those in SR 019 020
EN 319 162  Associated Signature Containers (ASiC)

This multipart document contains all the specifications related to the so-called Associated Signature Container. That is containers that bind together a number of signed data objects with Advanced Electronic Signatures applied to them or time-stamp tokens computed on them. This document includes the base specification and associated profiles, and in particular:

  • an Overview of ASiCand its profiles, and the relationship between them.
  • Associated Signature Containers (ASiC) – Core specifications:This document specifies the format for a single container binding together a number of signed objects (e.g. documents, XML structured data, spreadsheet, multimedia content) with either AdvancedElectronic Signatures or time-stamps. This uses package formats based on ZIP and supports the following signature and time-stamp token formats: CAdES signature(s) as specified in EN 319 122, XAdES detached signature(s) as specified in EN 319 132; and RFC 3161 [i.16] time-stamp tokens.
  • ASiC Baseline Profile:This document specifies a profile identifying a common set of options that are appropriate for maximizing interoperability between ASiC containers.

NOTE 1:  The baseline profile defines a baseline profile for ASiC that provides the basic features necessary for a wide range of business and governmental use cases for electronic procedures and communications to be applicable to a wide range of communities when there is a clear need for interoperability of AdES signatures, on which ASiC is based, to be interchanged across borders. In particular it takes into account needs for interoperability of AdES signatures used in electronic documents issued by competent authorities to be interchanged across borders in the context of the European Services Directive.
NOTE 2: When no specific use case would have requirements not satisfied by the baseline profile, no other specific profile will be added. Should it be otherwise, new profiles would be build on the baseline profile, unless the actual requirements would avoid it..
EN 319 172  Signature Policies
This document addresses signature policies to be used in the management of electronic signatures within extended business models. This is a multi-part document whose internal structure is shown below:

  • Part 1 – Signature Policies:This document elaborates the concept of signature policy documents, addresses relevant aspects of their usage, and specifies the constituent parts of a signature policy and their semantics.
    This provides a standardised table of content for human readable. It also includes a common EU signature policy which may be used for qualified electronic signatures and advanced electronic signatures supported by qualified certificates in Europe.
  • Part 2 – XML format for Signature Policies:This document specifies a XML format for those parts of the Signature Policy that may be structured and are worth to be automatically processed by both signing and verifying applications. This document also specifies the processes to be performed by the aforementioned applications while using this format during the generation or the validation of electronic signatures.
  • Part 3 – ASN.1 format for Signature Policies:This document specifies an ASN.1 format for those parts of the Signature Policy that may be structured and are worth to be automatically processed by both signing and verifying applications. This document also specifies the processes to be performed by the aforementioned applications while using this format during the generation or the validation of electronic signatures.

Conformity Assessment

EN 319 103  Conformity Assessment for Signature Creation and Validation Applications (& Procedures)
This document introduces the three aspects of assessment detailed in separate specifications:

a)  Assessment of user environment against policy requirements: the conformity rules for assessing conformity of SCA or SVA against Policy Requirements. This will show the complete process for performing complete assessment and make some reference to other conformity assessment guidance (including technical specifications, protection profiles, signature policies.
b)  Assessment of products and applications for electronic signature creation and validation against protection profiles.
c)  Assessment of conformity to Advanced Electronic Signature formats and protocols.
d)  Assessment of conformity of a specific machine processable signature policy to the business process policy requirements.
NOTE:  Assessment may require use of testing compliance or interoperability.

Testing Conformance & Interoperability

TS 119 104  General requirements on Testing Conformance & Interoperability of Signature Creation and Validation
This set of documents specifies general requirements for testing conformance and interoperability of signature creation and validation applications.
As a general principle, TS 119×04 documents are meant to group common requirements to all potential sub-parts with regards to testing conformance & interoperability. It could also be used as an introductory document to how testing conformance & integrity is dealt with in the sub-areas (e.g. general principles and requirements for PlugTests).
TS 119 124  CAdES Testing Conformance & Interoperability
This document provides technical specifications for helping implementers and accelerating the development of CAdES signature creation and validation applications. The test results may also be used in conformity assessment for signature creation and validation applications (EN 319 103) with policies requiring conformity to CAdES formats and procedures. First, it will define test suites as completelyas possible for supporting the organization of interoperability testing events where different CAdES related applications may check their actual interoperability. Additionally, it will include the specifications required for building up software tools for actually testing technical conformance of CAdES signatures against the relevant CAdES related technical specifications.
This is a multi-part document covering the following topics:

  • Test suites for testing interoperability of CAdES signatures:This document would be used by those entities interested in testing the interoperability of tools that generate and verify CAdES signatures not adhering to any specific profile, but compliant with the mother CAdES specification as defined in EN 319 122.
  • Test suites for testing interoperability of Baseline CAdES signatures:This document would be used by those entities interested in testing the interoperability of tools that generate and verify CAdES signatures that claim to be compliant with the CAdES Baseline Profile as specified in EN 319 122.
  • Specifications for testing conformance of CAdES Signatures:This document will specify, among other things, rules for testing conformance of signatures against the CAdES specification. It will allow developing a tool that can automatically check that a CAdES signature is fully conformant with the relevant aforementioned specifications, without claiming any statement on its validity.
  • Specifications for testing conformance of Baseline CAdES Signatures:This document will specify, among other things, rules for testing conformance of signatures against the CAdES Baseline Profile specification. It will allow developing a tool that canautomatically check that a CAdES Baseline signature is fully conformant with the relevant aforementioned specifications, without any statement on its validity.
  • Specifications for testing conformance of CAdES Signatures validation:This will allow developing a tool that can automatically check that a generated CAdES signature is fully conformant with the relevant aforementioned specifications and validate the signature according to EN 319 102.

NOTE 1:  A study should be made for assessing the need of a separate part for supporting conformance testing of signature validation.
NOTE 2:  A study should be made for assessing the need of an additional part for supporting the potential development and/or maintenance of a reference implementation.
TS 119 134  XAdES Testing Conformance & Interoperability
This document provides technical specifications for helping implementers and accelerating the development of XAdES signature creation and validation applications. The test results may also be used in conformity assessment for signature creation and validation applications (EN 119 103) with policies requiring conformity to XAdES formats and procedures. First, it will define test suites as completelyas possible for supporting the organization of interoperability testing events where different XAdES related applications may check their actual interoperability. Additionally, it will include the specifications required for building up software tools for actually testing technical conformance of XAdES signatures against the relevant XAdES related technical specifications.
This is a multi-part document structured as follows:

  • Test suites for testing interoperability of XAdES signatures:This document will be used by entities interested in testing tools that generate and verify XAdES signatures not adhered to any specific profile, but compliant with the mother XAdES specification as defined in EN 319 132.
  • Test suites for testing interoperability of Baseline XAdES signatures:This document will be used by entities interested in testing tools that generate and verify XAdES signatures that claim to be compliant with the XAdES Baseline Profile as specified in EN 319 132.
  • Specifications for testing conformance of XAdES Signatures:This document will specify, among other things, rules for testing conformance of signatures against the XAdES specification. It will allow developing a tool that can automatically check that generated XAdES signatures are fully conformant with the relevant aforementioned specifications, without any statement on their validity.
  • Specifications for testing compconformance liance of Baseline XAdES Signatures:This document will specify, among other things, rules for testing conformance of signatures against the XAdES specification. It will allow developing a tool that canautomatically check that a XAdES Baseline signature is fully conformant with the relevant aforementioned specifications, without claiming any statement on its validity.
  • Specifications for testing conformance of XAdES Signatures validation:This should allow developing a tool that could automatically check that the XAdES signatures generated by a certain tool are fully conformant with the relevant aforementioned specifications and validate the signature according to EN 319 102.

NOTE 1:  A study should be made for assessing the need of a separate part for supporting conformance testing of signature validation.
NOTE 2:  A study should be made for assessing the need of an additional part for supporting the potential development and/or maintenance of a reference implementation.
TS 119 144  PAdES Testing Conformance & Interoperability

This document provides technical specifications for helping implementers and accelerating the development of PAdES signature creation and validation applications. The test results may also be used in conformity assessment for signature creation and validation applications (EN 319 103) with policies requiring conformity to PAdES formats and procedures.
First, it will define test suites as completely as possible for supporting the organization of interoperability testing events where different PAdES related applications may check their actual interoperability. Additionally, it will include the specifications required for building up software tools for actually testing technical conformance of PAdES signatures against the relevant PAdES related technical specifications.
This is a multi-part document structured as follows:

  • Overview.
  • Test suites for testing interoperability of PAdES signatures:This document will be used by entities interested in testing tools that generate and verify PAdES signatures not adhered to any specific profile, but compliant with the mother PAdES specification as defined in EN 319 142.
  • Test suites for testing interoperability of Baseline PAdES signatures:This document will be used by entities interested in testing tools that generate and verify PAdES signatures that claim to be compliant with the PAdES Baseline Profile as specified in EN 319 142.
  • Specifications for testing compconformance liance of PAdES Signatures:This document will specify, among other things, rules for testing conformance of signatures against the PAdES specification. It will allow developing a tool that can automatically check that generated PAdES signatures are fully onformant with the relevant aforementioned specifications, without any statement on their validity.
  • Specifications for testing conformance of Baseline PAdES Signatures:This document will specify, among other things, rules for testing conformance of signatures against the PAdES Baseline Profile specification. It will allow developing a tool that could automatically check that a PAdES Baseline signature is fully conformant with the relevant aforementioned specifications, without claiming any statement on their validity or not.
  • Specifications for testing conformance of PAdES Signatures validation:This will allow developing a tool that can automatically check that a PAdES signature is fully conformant with the relevant aforementioned specifications and validates the signature according to EN 319 102.

NOTE 1:  A study should be made for assessing the need of a separate part for supporting conformance testing of signature validation.
NOTE 2:  A study should be made for assessing the need of an additional part for supporting the potential development and/or maintenance of a reference implementation.
TS 119 154   Testing Conformance & Interoperability of AdES in Mobile environments
This document will provide technical specifications for helping implementers and accelerating the development of creation and validation applicationsfor advanced electronic signatures in mobile environments.
TS 119 164  ASiC Testing Conformance & Interoperability
This document provides technical specifications for helping implementers and accelerating the development of ASiC containers creation and validation applications. The test results may also be used in conformity assessment for signature creation and validation applications (EN 319 103) with policies requiring conformity to ASiC formats and procedures.
First, it will define test suites as complete as possible for supporting the organization of interoperability testing events where different ASiC related applications may check their actual interoperability. Additionally, it will include the specifications required for building software tools for actually testing technical conformance of ASiC against the relevant ASiC related technical specifications.
This is a multi-part document covering the following topics:

  • Overview.
  • Test suites for testing interoperability of ASiC:This document will be used by entities interested in testing tools that generate and verify ASiC not adhered to any specific profile, but compliant with the mother ASiC specification as defined in EN 319 162.
  • Test suites for testing interoperability of Baseline ASiC:This document will be used by entities interested in testing tools that generate and verify ASiC that claim to be compliant with the ASiC Baseline Profile as specified in EN 319 162.
  • Specifications for testing conformance of ASiC:This document will specify, among other things, rules for testing conformance of signatures against the ASiC specification. It will allow developing a tool that can automatically check that generated ASiC are fully conformant with the relevant aforementioned specifications, without any statement on their validity.
  • Specifications for testing conformance of Baseline ASiC:This document will specify, among other things, rules for testing conformance of signatures against the ASiC specification. It will allow developing a tool that can automatically check that Baseline ASiC are fully conformant with the relevant aforementioned specifications, without claiming any statement on their validity.
  • Specifications for testing conformance of ASiC validation:This will allow developing a tool that can automatically check that ASiC are fully conformant with the relevant aforementioned specifications and that validates the signature according to EN 319 102.

NOTE 1:  A study should be made for assessing the need of a separate part for supporting conformance testing of signature validation.
NOTE 2:  A study should be made for assessing the need of an additional part for supporting the potential development and/or maintenance of a reference implementation.
TS 119 174   Testing Conformance & Interoperability of Signature Policies
This document provides technical specifications for helping implementers and accelerating the development of Signature Policies. The test results may also be used inconformity assessment for signature creation and validation applications (EN 319 103) with policies requiring conformity to machine processable Signature Polices format specifications.
First, it will define test suites as complete as possible for supporting the organization of interoperability testing facilities where different Signature Policy based applications may check their actual interoperability.
Additionally, it will include the specifications required for building software tools for actually testing technical conformance of machine processable Signature Policies against the relevant technical specifications.

Defined documents: Signature related devices

Guidance

TR 419 200  Business Driven Guidance for Signature Creation and Other Related Devices
This document provides guidance for the selection of standards for electronic signature devices for given business requirements.

Policy & Security Requirements

Policy and Security Requirements for Signature Creation Devices

No requirement has been identified for this type of document as requirements for the use of signature creation devices is addressed as part of the policy requirements of the signing environment in EN 319 101.

EN 419 211  Protection Profiles for Secure Signature Creation Devices
This document specifies the security requirements for a SSCD which is the target of evaluation. It follows the rules and formats of the Common Criteria v3.
This is a multi-part document covering the following topics:

  • Part 1- Overview: An introduction to the SSCD protection profiles.
  • Part 2 – Device with key generation:This document specifies a protection profile for an SSCD that performs its core operations including the generation of signature keys in the device. This profile may be extended through extensions specified in other parts.
  • Part 3 – Device with key import: This document specifies a protection profile for an SSCD that performs its core operations including import of the signature key generated in a trusted manner outside the device.
  • Part 4 – Extension for device with key generation and trusted communication with certificate generation application: This document specifies an extension protection profile for an SSCD with key generation that support establishing a trusted channel with a certificate-generating application. This profile may be extended through extensions specified in other parts.
  • Part 5 – Extension for device withkey generation and trusted communication with signature creation application: This document specifies an extension protection profile for an SSCD with key generation that additionally supports establishing a trusted channel with a signature-creation application.
  • Part 6 – Extension for device with key import and trusted communication with signature creation application:This document specifies an extension protection profile for an SSCD with key import that additionally supports establishing a trusted channel with a signature-creation application.Additional protection profiles or other form of security certification and security evaluation processes may be required, to ensure that they offer the relevant level of security, for other types of devices such as, e.g.:
    • Mobile phones with hardware-based security (TEE, MTM, etc.).
    • HSM being recognised as an SSCD.
    • SSCD used for mass signing operations (e.g. for signing a series of documents).

EN 419 221  Protection profiles for TSP Cryptographic modules

This multi-part document specifies protection for cryptographic device devices used by Trust Service Providers. It covers the following topics:

  • Part 1 – Overview: This part of EN 419 221 provides an overview of the protection profiles specified in other parts of TS 419 221.
  • Part 2 – Protection profile for Cryptographic module for CSP signing operations with backup – high security level: This part of EN 419 221 specifies a protection profile for cryptographic modules used by certification service providers (as specified in Directive 1999/93 [i.1]) for signing operations, with key backup, at a high level of security. Target applications include root certification authorities (certification authorities who issue certificates to other CAs and who are at the top of a CA hierarchy) and other certification service providers where there is a high risk of direct physical attacks against the module.
  • Part 3 – Protection profile for Cryptographic module for CSP key generation services – high security level: This part of EN 419 221 specifies a protection profile for cryptographic modules used by certification service providers (as specified in Directive 1999/93 [i.1]) for generating signing keys for use by other parties, at a high level of security. Target applications include root certification authorities and other certification service providers where there is a high risk of direct physical attacks against the module.
  • Part 4 – Protection profile for Cryptographic module for CSP signing operations – high security level: This part of EN 419 221 specifies a protection profile for cryptographic modules used by certification service providers (as specified in Directive 1999/93 [i.1]) for signing operations, without key backup, at a high level of security. Target applications include root certification authorities (certification authorities which issue certificates to other CAs and is at the top of a CA hierarchy) and other certification service providers where there is a high risk of direct physical attacks against the module.
  • Part 5: Protection profile for Cryptographic module for TSP signing and authentication – moderate security level: This part of EN 419 221 specifies a protection profile for cryptographic modules used by trust service providers for signing operations and authentication services at a moderate level of security. This protection profile includes support for protected backup of keys. The target of this part is:
    a)  provision of cryptographic support for TSP signing operations including applications such as certification authorities who issue qualified and non-qualified certificates to end users, level 1 signing services as identified in EN 419 241, data “sealing” by or on behalf of a legal entity, time-stamping services and validation services; and
    b)  provision of both symmetric and asymmetric cryptographic support for TSP authentication services, for example for authenticating users of signing services as specified in EN 419 241. This profile assumes that the cryptographic module is in a physically secured environment and that there is a low risk of untrusted personnel having direct physical access to the device.

EN 419 231  Security requirements for trustworthy systems supporting time-stamping
This document defines security requirements for a time-stamping system which consists of at least a time-stamping unit (a set of hardware including an internal clock and software creating time-stamp tokens) and of administration and auditing used to provide time-stamping services.

Informative annexes will provide check lists for conformity assessment.

EN 419 241  Trustworthy Systems Supporting Server Signing
This document is to become a multi-part document including general security requirements and protection profiles for Trustworthy Systems (TWSs) supporting server signing. The document is intended for use by developers and evaluators of a Server Signing Application and of its components. The details for this document have yet to be agreed in CEN TC 224 Working Group 17.
EN 419 251  Protection Profiles for Authentication Devices
This multi-part document defines security requirements for conformity of an authentication hardware device (such as, for example, a smart card or USB token) from the perspective of a security evaluation.
This multi-part document covers the following aspects:

  • Part 1defines a PP for a device with only the core features and key import. It is the minimum product.
  • Part 2defines a PP for a device with key import, key generation, trusted channel with the CA, trusted channel with the Administration application and administration.
  • Part 3defines additional featuresthat can be added to part 1 or part2 in order to define a new PP with enhanced features.

EN 419 261  Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures

Requirements
This document establishes security requirements for trustworthy systems and technical components that can be used by a TSP in order to issue qualified and non-qualified certificates.

Technical specifications

EN 419 212  Application Interfaces for Secure Signature Creation Devices
This standard describes an application interface and behaviour of the SSCD in the context of Identification, Authentication and Electronic Signature (IAS) services.

This is a multi-part document covering the following topics:

  • Part 1: Introduction.
  • Part 2 describesBasic services for electronic signatures:This document specifies mandatory mechanisms for cryptographic devices such as smart cards, hardware security modules to be used as SSCD, and covers user validation, signature creation, device authentication, password-based mechanisms, establishment of a secure channel and key generation.
  • Part 3 describesAdditional servicesin the context of electronic signatures:This document specifies mechanisms to support services around Identification, Authentication and Digital Signature (IAS) services in addition to the SSCD mechanisms already described in Part 1 to enable interoperability and usage for IAS services on a national or European level. It also specifies additional mechanisms like Client/Server authentication, role authentication, symmetric key transmission between a remote server and a smart card, signature cryptographic verification, identity management and privacy mechanisms.
  • Part 4 describesContext specific authentication protocols for SSCDs:This document specifies context specific authentication protocols for SSCDs, covering first the migration to suitable Authentication Protocols, e.g. for further context specific use for other transport layers e.g. NFC, and second a glossary including the unambiguous definition of the security properties employed by the proposed protocols.

Conformity Assessment
EN 419 203  Conformity Assessment of Secure Devices and Trustworthy systems
This document provides guidance on conformity assessment of Secure Creation Devices against the specifications EN 419 211 and guidance on conformity assessment for trustworthy systems against the specifications EN 419 221, EN 419 231, EN 419 241, EN 419 251 and EN 419 261.The guidance is intended for use by designated bodies, assessors, evaluators and manufacturers. Technical Conformance & Interoperability Testing
No requirements identified so far for such a document.

Defined documents: Cryptographic Suites

Guidance
TR 119 300  Business Driven Guidance for Cryptographic Suites
This document provides guidance for the selection of cryptographicsuites for given business requirements.
NOTE:  Regular maintenance of cryptographic suites specifications should be ensured and mechanisms for ensuring this should be proposed and implemented.

Technical Specifications
TS 119 312  Cryptographic Suites for Secure Electronic Signatures
This document defines a number of cryptographic suites for secure electronic signatures including a list of hash functions and a list of signature schemes, as well as the recommended combinations of hash functions and signatures in the form of “signature suites” to support Advanced Electronic Signatures.
Technical Conformance & Interoperability Testing
No requirements identified so far.

Defined documents: TSPs Supporting Electronic Signatures

Guidance

TS 119 400  Business Driven Guidance for TSPs Supporting Electronic Signatures
This document provides guidance for the selection of standards for TSPs for given business requirements.
NOTE:  When there would be a need for identifying and producing specific Business Driven Guidance for specific types of TSPs supporting electronic signatures, the Rationalised Framework model allows usage of TR 119 410, TR 119 420, TR 119 430, etc. documents for such purpose.

Policy & Security Requirements

EN 319 401  General Policy Requirements for TSPs Supporting Electronic Signatures
This document specifies policy requirements for TSPs Supporting Electronic Signatures that are independent of the type of TSP.
EN 319 411  Policy & Security Requirements for TSPs Issuing Certificates
This multi-part document specifies policy and security requirements for TSPs issuing certificates. It references EN 319 401 for generic requirements.
This is a multi-part document including the following topics:

  • Part 1 – Overview: This part provides an overview of the other parts of this document. It also describes the relationship of the policy requirements defined in this area and the use of secure devices and trustworthy systems defined in the “Signature Creation and Other Related Device” area.
  • Part 2 – Policy requirements for TSP issuing qualified certificates.
  • Part 3 – Policy requirements for TSP issuing public key certificates.
  • Part 4 – Policy requirements for TSP issuing web site certificates.
  • Part 5 – Policy requirements for TSP issuing Attribute Certificates.

Informative annexes will provide check lists for conformity assessment.
EN 319 421  Policy & Security Requirements for TSPs providing Time-Stamping Services

This document specifies policy requirements for TSPs providing Time-stamping services based on RFC 3161. It references EN 319 401 for generic requirements.
Similarly to EN 319 411, this multi-part document may be organised to include the following topics:

  • Overview: This part provides an overview of the other parts of this document. It also describes the relationship of the policy requirements defined in this area and the use of secure devices and trustworthy systems defined in the “Signature Creation and Other Related Device” area.
  • Policy requirements for TSPs providing Time-stamping services. Informative annexes will provide check lists for conformity assessment.

EN 319 431  Policy & Security Requirements for TSPs providing Signature Generation Services

This document specifies policy requirements for TSPs providing signature generation services. It references EN 319 401 for generic requirements.

Similarly to EN 319 411, this multi-part document may be organised to include the following topics:

  • Overview: This part provides an overview of the other parts of this document. It also describes the relationship of the policy requirements defined in this area and the use of secure devices and trustworthy systems defined in the “Signature Creation and Other Related Device” area.
  • Policy requirements for TSPs providing Signature Generation services. Informative annexes will provide
    check lists for conformity assessment.

EN 319 441  Policy & Security Requirements for TSPs providing Signature Validation Services
This document specifies policy requirements for TSPs providing Signature Validation Services. It references EN 319 401 for generic requirements.
Similarly to EN 319 411, this multi-part document may be organised to include the following topics:

  • Overview: This part provides an overview of the other parts of this document. It also describes the relationship of the policy requirements defined in this area and the use of secure devices and trustworthy systems defined in the “Signature Creation and Other Related Device” area.
  • Policy & Security requirements for TSPs providing Signature Validation services. Informative annexes will provide check lists for conformity assessment.

Technical Specifications

EN 319 412  Profiles for TSPs issuing Certificates
This document provides specifications for specific profiles applicable to TSPs issuing certificates including qualified and other forms of certificates. It provides certificate profiles and a profile extension which aim to facilitate interoperability of (qualified) certificates issued to natural person, legal person or to organisation as website certificate,
for the purposes of (qualified) electronic signatures, (qualified) electronic seals, peer entity authentication, data authentication, as well as data confidentiality.
This is a multi-part document including the following topics:

  • Part 1 – Overview.
  • Part 2 – Certificate profile for certificates issued to natural persons.
  • Part 3 – Certificate profile for certificates issued to legal persons.
  • Part 4 – Certificate profile for website certificates issued to organisation (Baseline and Extended Validation).
  • Part 5 – Qualified certificate statements for qualified certificate profiles.

EN 319 422  Profiles for TSPs providing Time-Stamping Services
This document specifies a profile for the format and procedures for time-stamping as specified in RFC 3161.
EN 319 432  Profiles for TSPs providing Signature Generation Services
This document specifies a profile for the format and procedures for TSPs providing Signature Generation Services.
EN 319 442  Profiles for TSPs providing Signature Validation Services
This document specifies a profile for the format and procedures for TSPs providing Signature Validation Services.

Conformity Assessment

EN 319 403  Trust Service Provider Conformity Assessment – Requirements for conformity assessment bodies assessing Trust Service Providers
This document contains requirements for the competence, consistent operation and impartiality of conformity assessment bodies assessing conformity of Trust Service Providers (TSP) to standardized criteria for the provision of trust services. Requirements and guidance set out in the present document are independent of the class of trust service provided.
EN 319 413  Conformity Assessment for TSPs Issuing Certificates
This (multi-part) document specifies requirements and provides guidance for the assessment of TSPs issuing certificates.
NOTE:  It may be assumed that any requirement relating to completion of conformity testing might be covered here and reference the appropriate Technical Conformance & Interoperability Testing documents.
This is a multi-part document including the following topics:

  • Conformity Assessment for Policy Requirements for TSP issuing Certificates.

EN 319 423  Conformity Assessment for TSPs providing Time-Stamping Services
This document specifies requirements and provides guidance for the assessment of TSPs providing time-stamping services.
This is a multi-part document including the following topics:

  • Conformity Assessment for Policy Requirements for TSP providing time-stamping services

EN 319 433  Conformity Assessment for TSPs providing Signature Generation Services

This document specifies requirements and provides guidance for the assessment of TSPs providing Signature

Generation Services.

This is a multi-part document including the following topics:

  • Conformity Assessment for Policy Requirements for TSP providing Signature Generation Services.

EN 319 443  Conformity Assessment for TSPs providing Signature Validation Services
This document specifies requirements and provides guidance for the assessment of TSPs providing Signature Validation Services.

 
This is a multi-part document including the following topics:

  • Conformity Assessment for Policy Requirements for TSP providing Signature Validation Services.

Testing Conformance & Interoperability

Not applicable so far.
NOTE:  At the current date, no requirement for such documents has been identified. It may however be the case that specifications for conformity checker tools could be identified in the future such as conformity checker for generated Trust Service tokens such as qualified certificates, public key certificates against a specific profile, or time-stamp tokens.

Defined documents: Trust Application Service Providers

Guidance

TR 119 500  Guidance for Trust Application Service Provider

This document provides guidance for the selection of standards for trusted application service providers for given business requirements.
The document identifies a number of relevant Trusted Application Services using electronic signatures in different business areas, and whose provision has already been standardized. Additionally, for each of the services, it provides guidance for the selection of the suitable standards, ensuring in this way their correct provision and interoperability across the European Union.
SR 019 530  Study on standardisation requirements for e-Delivery services applying e-Signatures

This document will define Electronic Delivery (e-delivery) services and investigate applicable requirements from those existing in the market (ETSI, CEN, private standards and pilots’ outcome) proposing rationalised and well organized requirements for Electronic Delivery Applying Electronic Signatures and its possible relation to Registered E-Mail.

Policy & Security Requirements

EN 319 511  Policy & Security Requirements for Registered Electronic Mail (REM) Service Providers
This document specifies policy and security requirements for REM service providers required to be recognized as a provider of this type of services. It might define different conformity levels for each style of operation and the corresponding set of requirements to be satisfied in each level. This document also addresses requirements on Information Security Management and Security requirements for REM systems. It references EN 319 501 for generic requirements.
NOTE:  Whether a “Security (Protection) Profile for Trustworthy systems used by REM Service Providers” should be merged within those specific policy & security requirements is yet to be further analysed.
This multi-part document includes:

  • Overview. This part provides an overview of the other parts of this document. It also describes the relationship of the policy requirements defined in this area and the use of secure devices and trustworthy systems defined in the “Signature Creation and Other Related Device” area.
  • Policy requirements for REM Service Providers.
    Informative annexes will provide check lists for conformity assessment.

EN 319 521   Policy & Security Requirements for Data Preservation Service Providers (DPSPs)
This document specifies policy and security requirements for DPSPs. It references EN 319 501 for generic requirements.
It may address specific Information Security Management Systems or Data Preservation Systems (DPS), by specifying specific security requirements for Data Preservation Service Providers to abide by, when implementing and managing a DPS, in order to provide Data Preservation Services that are trustable and reliable from the Information Security viewpoint. This document does not address any   archival specific issues, like definition of data metadata structure and methods to build them, links between data to implement virtual folders, etc.
NOTE:  Whether a “Security (Protection) Profile for Trustworthy systems used by Data Preservation Service Providers” should be merged within those specific policy & security requirements is yet to be further analysed.
This multi-part document includes:

  • Overview. This part provides an overview of the other parts of this document. It also describes the relationship of the policy requirements defined in this area and the use of secure devices and trustworthy systems defined in the “Signature Creation and Other Related Devices” area.
  • Policy requirements for Data Preservation Service Providers.
    Informative annexes will provide check lists for conformity assessment.

Technical Specifications

EN 319 512  Registered Electronic Mail Services
This document provides technical specifications for the provision of Registered Electronic Mail. This is a multi-part document whose structure is detailed below:

  • Framework, Architecture and Evidence:This is a document structured in three sub-parts, as detailed below:
    • Registered Electronic Mail Overview
    • a framework document:This document provides an overview of the whole set of specifications included in the Technical Specification.
    • Architecture:This document provides an overall view of the standardized service, addressing the following aspects:
      • Logical model, namely: components, styles of operation,
      • Roles within a service provider, grouping of providers in administrative domains.
      • Interfaces between the different roles and providers.
      • Relevant events in the data objects flows and the corresponding evidence.
        Trust building among providers pertaining to the same or to different administrative domains.
    • Evidence semantics and format:This document fully specifies the set of evidence managed in the context of the service provision. The document fully specifies the semantics, the components, and the components’ semantics for all the evidence. The document also specifies different formats for all the
      evidence in different syntax, namely: XML, ASN.1 and PDF.
  • Messages formats and bindings:This part specifies different formats for the messages and the different bindings for different transport protocols. This is a document structured in two sub-parts, as detailed below:
    • SMIME on SMTP. This document specifies the format of the data objects when SMIME structures are used for conveying them, and when the transport protocol used is SMTP.
    • SOAP on HTTP:This document specifies the format of data objects when SOAP structures are used for conveying them, and when the transport protocol used is HTTP.
  • Interoperability profiles:This part contains several sub-parts. Each sub-part specifies profile(s) for seamless exchange of data objects across providers that use different formats and/or transport protocols.

NOTE 1:  Its internal structure will very much depend on the different relevant systems specified and built across Europe, as during the last years a number of specifications and non interoperable systems based on them, have been developed.
NOTE 2:  Requirements for support of Registered Electronic Delivery requires further investigation.
EN 319 522  Data Preservation Services through signing
This document specifies technical requirements for services providing document signing in support of data preservation. It specifies the requirements on the use of electronic signatures and time-stamping to maintain the authenticity and integrity of documents when stored over long periods. This can be applied to a single document or a set of documents, including multi-media objects, held in a container. An initial study will identify standardisation requirements and how this relates to general standardisation for archiving and data preservation. Conformity Assessment
EN 319 513  Conformity Assessment of Registered Electronic Mail Service Providers
This document specifies requirements and provides guidance for the supervision and assessment of a Registered Electronic Mail Service Provider based on general requirements and guidance for conformity assessment specified in EN 19 403.
EN 319 523  Conformity Assessment of Data Preservation Service Providers
This document specifies requirements and provides guidance for the supervision and assessment of a DPSP based on general requirements and guidance for conformity assessment specified in EN 319 403.

Testing Conformance & Interoperability

TS 119 504  General requirements for Technical Conformance & Interoperability Testing for Trust Application Service Providers
This document specifies general requirements for specifying technical conformance and interoperability testing for TASPs.

TS 119 514  Testing Conformance & Interoperability of Registered Electronic Mail Service Providers
This document defines test suites that support interoperabilitytests among entities that plan to provide this type of services. This is a multi-part document, whose structure is detailed below:

  • Test suites for interoperability testing of providers using same format and transport protocols:This document is for those providers that implement the service provision using the same combination of format and transport protocols, i.e. there will be two test-suites one for the providers using SMIME on SOAP and another for those using SOAP on HTTP.
  • Test suites for interoperability testing of providers using different format and transport protocols: This document is for those providers that implement the service provision using different combinations of format and transport protocols. This document defines test-suites for the interoperability profiles for REM.
  • Testing conformance:This document specifies the tests to be performed for checking conformity against EN 319 512. This provides the basis for a tool that automatically checks that the messages and evidence set generated by a certain provider are fully conformant with the relevant aforementioned specifications.

Defined documents: Trust Service Status Lists Providers

Guidance

TR 119 600  Business Driven Guidance for Trust Service Status Lists Providers
This document provides guidance for the selection of standards for Trusted Service Status Lists Providers for given business requirements.

Policy & Security Requirements

EN 319 601  General Policy & Security Requirements for Trust Service Status Lists Providers
This document will specify general policy and security requirements for providers issuing status information of trusted services. It will describe different models on which such providers may operate, how this influences the way the content of the lists should be interpreted and specific criteria for the provision of revisions to TSL information, which should be published by the providers.
EN 319 611  Policy & Security Requirements for Trusted List Providers
This document will specify specific policy requirements for issuers of Trusted List, a profile of Trust Service Status List, as they are defined in CD 2009/767/EC [i.19] as amended by CD 2010/425/EU [i.20]. This would build on the requirements in EN 319 601.
Technical Specifications
TS 119 602  Trust Service Status Lists Format

This document will contain specifications related to Trust Service Status Information Formats (Trust Service Lists – TSL). This may be a multi-part document including:

  • Trust Service Status Lists Structure
    This part specifies the Trust Service Status List structure. Each of the fields within the TSL is described to a level of detail sufficient to derive a consistent format specification.
  • ASN.1 Representation of Trust Service Status Lists
    This part specifies the ASN.1 structures to be used when implementing an ASN.1-version of TSLs.
  • XML Representation of Trust Service Status Lists
    This part specifies the XML structures to be used when implementing an XML-version of TSLs.

TS 119 612  Trusted Lists
This document contains the specifications related to Trusted Lists (TL) for their use in the context of Directive 1999/93/EC [i.1] and of the Services Directive 2006/123/EC [i.14], as they are defined in CD 2009/767/EC  amended by CD 2010/425/EU.
NOTE 1: Migration of this TS as an EN is not planned yet and will depend on the adoption of the proposal for a regulation on electronic identification and trust services for electronic transactions in the internal market that will supersede Directive 1999/93/EC.
NOTE 2:  As conceptually TL or TSL can be used for providing status information on the approval of any type of provision of any type of Trust Service Token by any type of Trust Service Provider, the document structure proposed here is flexible enough to allocate sub-areasto determined categories of such services. As an example, TL or TSL could be used for publishing in a Europe-wide common way, the status of the determination of conformity of a signature creation device against the requirements laid down in Annex III of Directive 1999/93/EC [i.1] (SSCD) made by a Member State Designated Body. It is likely that for such a purpose, a specific baseline profile of TL specifications as per TS 119 612 would be required.

Conformity Assessment

EN 319 603  General requirements and guidance for Conformity Assessment of TSSLPs

This document will provide the rationale, rules and guidance on conformity assessment concerning the processes and products around the issuance and processing of Trust Service Status Lists.
EN 319 613  Conformity Assessment of Trusted List Providers

This document will specify the specific conformity rules for assessing conformity against

EN 319 612 specifications related to both the generation and conformity validation of Trusted Lists, a profile of Trust Service Status Lists.

Testing Conformance & Interoperability

TS 119 604  General requirements for Testing Conformance & Interoperability of TSLs

This document will specify general requirements for specifying technical conformance and interoperability testing for TSLs. This may include test suites and specifications for conformity testing tools testing ASN.1 and /or XML representation of TSLs. This document will be used by those entities interested in testing tools that generate and verify Trust Service Status Lists in their ASN.1 or XML representation compliant with the specification TS 119 602. This is a multi-part document that includes:

  • Testing specifications for technical conformance & interoperability testing of ASN.1 representation of the Trust Service Status Lists:This document will be used by those entities interested in testing tools that generate and verify Trust Service Status Lists in its ASN.1 representation conformant with the specification TS 119 602.
  • Testing specifications for technical conformance & interoperability testing of XML representation of the Trust Service Status Lists:This document will be used by those entities interested in testing tools that generate and verify Trust Service Status Lists in their XML representation conformant with the specification TS 119 602.

TS 119 614  Test suites and tests specifications for Technical Conformance & Interoperability Testing of Trusted Lists
This document provides technical specifications for helping implementers and accelerating the development of tools for creating and issuing Trusted Lists. First, it will define test suites as completely as possible for supporting the organization of interoperability testing events where different Trusted List related applications may check their actual interoperability. Additionally, it will include the specifications required for building up software tools for actually testing technical conformance of Trusted Lists against the relevant Trusted List related technical specifications:

  • Test suites for testing interoperability of XML representation of Trusted Lists:This document will be used by those entities interested in testing tools that generate and verify Trusted Lists in their XML representation compliant with TS 119 612.
  • Specifications for testing conformance of XML representation of Trusted Lists:This document will specify, among other things, rules for testing compliance ofTrusted Lists against Trusted List specifications. It should include not only rules for the static aspects of the Trusted Lists, i.e. the contents of a certain instantiation of the Trusted List, but also rules for testing dynamic aspects of the Trusted List, i.e. specific relationships among elements present in consecutive instantiations of one Trusted List as a result of certain very well specified events (Trusted List life cycle-related rules). It should allow developing a tool that could automatically check that the Trusted Lists generated by a certain tool are fully conformant with the relevant aforementioned specifications.

Cartulario electrónico (o digital)

1 respuesta

Según la RAE una acepción de Cartulario es la que se refiere al  Escribano, y principalmente el de número de un juzgado, o el notario en cuyo oficio se custodian las escrituras de que se habla.

En el ámbito de la Diplomática, según el artículo de Concepción Mendo,  recogido por Lía González, los cartularios son copias de documentos, recibidos por personas o entidades, que se transcriben completos o en extractos para asegurar su conservación y facilitar su consulta. Sirven como testimonio de la sociedad del momento, del estado de cuentas y propiedades de iglesias, monasterios y conventos; y de los cambios experimentados en la demografía, la cultura y las lenguas.

El cartulario es un documento público cuyo valor, como documento histórico, depende de la fidelidad con la que se reproduce el sentido sustancial del original.

La creación de los cartularios, a lo largo de su historia, está vinculada a situaciones de crisis y reformas administrativas o culturales. En estas circunstancias, en las que las se hace necesario localizar títulos relativos a bienes y derechos o documentos concernientes a la fundación o administración de entidades, los cartularios cumplen con la finalidad de facilitar la consulta de los documentos conservados en los archivos y servir como instrumento probatorio para que las instituciones puedan conocer y hacer valer sus derechos de propiedad frente a terceros.

Según Carlos Sáez los cartularios se pueden clasificar en tres grupos: “los primitivos consistían en la agrupación de originales cosidos y encuadernados, un segundo tipo son aquellos en los que se copia por extenso el texto de los documentos originales y finalmente están los que recogen un resumen del original”.

En pleno siglo XXI aparecen los cartularios electrónicos, como cartulario.net (cuya página inicial en estos momento redirige a noticeman.net), que recogen documentos electrónicos auténticos identificables con código seguro de verificación (CSV). Son servicios de «Tercero de Confianza» (y a partir de la entrada en vigor del futuro Reglamento eIDAS servicios de preservación de documentos electrónicos auténticos englobados entre los que ofrecen los Prestadores de Servicios de Confianza Digital).

Estos servicios garantizan que los documentos cuya custodia se delega a prestadores especializados no pueden modificarse por ninguno de los intervinientes, ni siquiera el que los creó originalmente, y pueden ser utilizados como prueba en juicio o en cualquier otro procedimiento de resolución de controversias (como la Negociación, la Mediación, el Arbitraje  o el Pleito).

Además, si están bien diseñados, permiten recuperar el concepto de «original electrónico» y aportar funcionalidades como la endosabilidad, obliterabilidad y completitud, ya mencionados en otros artículos de este blog.

Filosóficamente se alinean con los documentos «matriz» de los protocolos notariales.

La extensión de algunos principios de la diplomática clásica al medio digital da lugar a la diplomática digital.

Ver otros artículos relacionados:

XVII Edición Master en Negocio y Derecho de las Telecomunicaciones, Internet y Audiovisual

Deja un comentario

Este año se celebra la XVII Edición del Master en Negocio y Derecho de las Telecomunicaciones, Internet y Audiovisual organizado por el despacho Cremades & Calvo-Sotelo, en colaboración con el Centro Universitario Villanueva, y al que amablemente me han invitado, una vez más, como profesor.

El MNDTIA tiene como objetivo la formación altamente cualificada de abogados que deseen ejercer la abogacía en el sector de las telecomunicaciones, combinando los conocimientos teóricos específicos de esta rama del derecho con la realización de prácticas en empresas líderes del sector y en nuestro Despacho.

El MNDTIA es el master pionero en materia de telecomunicaciones & TIC en España, se viene impartiendo desde hace 16 años y ha sido diseñado por reputados profesionales especialistas del sector, y pensado para aquellos que quieran crecer profesionalmente adquiriendo conocimientos especializados en una rama del derecho que abarca uno de los sectores que más profundamente se ha visto transformado en los últimos años y uno de los que mayor potencial de futuro aguarda debido a la revolución digital.

Yo impartiré la sesión de Firma Digital, introduciendo algunos conceptos de Diplomática Digital.