DigiDoc security model

The general security model of the DigiDoc and OpenXAdES ideology works by obtaining
proof of validity of the signer’s X.509 digital certificate issued by a certificate authority (CA) at
the time of signature creation.

This proof is obtained in the format of Online Certificate Status Protocol (OCSP) response
and stored within the signed document. Furthermore, (hash of the) created signature is sent
within the OCSP request and received back within the response. This allows interpreting of
the positive OCSP response as “at the time I saw this digitally signed file, corresponding
certificate was valid”.

The OCSP service is acting as a digital e-notary confirming signatures created locally with a
smart card. From infrastructure side, this security model requires a standard OCSP
responder. Hash of the signature is placed on the “nonce” field of the OCSP request
structure. In order to achieve the freshest certificate validity information, it is recommended
to run the OCSP responder in “real-time” mode meaning that:

• certificate validity information is obtained from live database rather than from
  CRL (Certificate Revocation List)
• the time value in the OCSP response is actual (as precise as possible)

To achieve long-time validity of digital signatures, a secure log system is employed within the
model. All OCSP responses and changes in certificate validity are securely logged to
preserve digital signature validity even after private key compromise of CA or OCSP
responder. It is important to notice that additional time-stamps are not necessary when
employing the security model described:

• time of signing and time of obtaining validity information is indicated in the OCSP
  response
• the secure log provides for long-time validity without need for archival
  timestamps 

MySQL’s Core Feature Set for Data Warehousing

MySQL contains a solid core feature set that is suitable for all data warehousing use cases. The following
are just some of the features in the MySQL database server that help enable data warehousing:

• Data/Index partitioning – available in MySQL 5.1 and higher; supports range, hash, key, list, and
  composite partitioning. Partition “pruning” is available, which involves MySQL only examining the
  partitions it needs to satisfy a particular query instead of an entire table or index. Partition
  management is also supported (ADD PARTITIION, DROP PARTITION, etc.)
• No practical storage limits – for example, 1 tablespace=110TB limit
• Automatic storage management – autogrowth data files, etc.
• ANSI-SQL support for all datatypes – including BLOB and XML
• Built-in Replication – simple and easy to configure
• Main memory tables – keeps all data in-resident in RAM; perfect for dimension tables
• Support for a variety of indexes – B-tree, fulltext, clustered, hash, GIS
• Multiple-configurable data/index caches
• Pre-loading of index data into index caches
• Unique query cache – caches result set + query, not just data and therefore provides near
  instantaneous response times for repetitive queries like those used in data warehousing
• Parallel data load – loads multiple files at the same time
• Multi-insert DML – allows array-style processing via normal INSERT commands
• Data compression – provides enormous storage savings
• Read-only tables – protects sensitive data
• Encryption – further protection for sensitive data
• Cost-based optimizer – eliminates need for rule-based query writing
• Wide platform support – no need for special hardware or operating systems

Specialized Parallel Relational Operators

Some algorithms for relational operators are especially appropriate for parallel execution,
either because they minimize data flow, or because they better tolerate data and execution skew.
Improved algorithms have been found for most of the relational operators. The evolution of join
operator algorithms is sketched here as an example of these improved algorithms.

Recall that the join operator combines two relations, A and B, to produce a third relation
containing all tuple pairs from A and B with matching attribute values. The conventional way of
computing the join is to sort both A and B into new relations ordered by the join attribute. These
two intermediate relations are then compared in sorted order, and matching tuples are inserted in
the output stream. This algorithm is called sort-merge join.

Many optimizations of sort-merger join are possible, but since sort has execution cost
nlog(n), sort-merge join has an nlog(n) execution cost. Sort-merge join works well in a parallel
dataflow environment unless there is data skew. In case of data skew, some sort partitions may
be much larger than others. This in turn creates execution skew and limits speedup and scaleup.
These skew problems do not appear in centralized sort-merge joins.

Hash-join is an alternative to sort-merge join. It has linear execution cost rather than
nlog(n) execution cost, and it is more resistant to data skew. It is superior to sort-merge join
unless the input streams are already in sorted order. Hash join works as follows. Each of the
relations A and B are first hash partitioned on the join attribute. A hash partition of relation A is
hashed into memory. The corresponding partition of table relation B is scanned, and each tuple
is compared against the main-memory hash table for the A partition. If there is a match, the pair
of tuples are sent to the output stream. Each pair of hash partitions is compared in this way.

The hash join algorithm breaks a big join into many little joins. If the hash function is
good and if the data skew is not too bad, then there will be little variance in the hash bucket size.
In these cases hash-join is a linear-time join algorithm with linear speedup and scaleup. Many
optimizations of the parallel hash-join algorithm have been discovered over the last decade. In
pathological skew cases, when many or all tuples have the same attribute value, one bucket may
contain all the tuples. In these cases no algorithm is known to speedup or scaleup.

Existing Graph Based Stream Authentication Methods Using Crypto Signatures

For graph-based authentication, the main challenge is how to design a Directed Acyclic Graph (DAG)
with lowest overhead, highest verification probability and lowest sender and receiver delay.
However, there are tradeoffs between these performance criteria, which are summarized below.

• Computation complexity: The number of hash operations and signature operations required at the
  sender and receiver. Note that computing a signature is much more complex than computing a hash.

• Overhead size: The extra bytes introduced by stream authentication, including the hashes and
  signatures appended to the packets. The overhead size is determined by the number of edges in
  the authentication graph. Note that a signature is much bigger in size than a hash.

• Verification percentage (or verification probability): the percentage of verifiable packets
  among all the received packets. Intuitively, the more redundant paths a packet has to the
  signature packet, the higher the probability of being verified.

• Sender delay: The delay at the sender (in number of packets) from the time when the packet
  is produced by the encoder to the time that all authentication data appended to this packet
  is ready. Real-time communication scenario requires low sender delay. For non-real-time
  scenario, e.g., pre-encoded content for VOD applications, it is not important because the
  sender has priori knowledge of all packets.

• Receiver delay: The delay at the receiver (in number of packets) from the time a packet is
  received to the time that it can be verified. For authenticated video, each packet must be
  received and pass the verification before its playout deadline.