Page 28 - ITU Journal - ICT Discoveries - Volume 1, No. 2, December 2018 - Second special issue on Data for Good

ITU JOURNAL: ICT Discoveries, Vol. 1(2), December 2018

of the sidechain. The absence of a precedingBlock
attribute or the presence of a parentBlock attribute
indicate that a sidechain root block has been
located when traversing the chain of blocks.

The parentBlock attribute is defined using ASN.1 as
follows:

parentBlock ATTRIBUTE ::= {
WITH SYNTAX ParentBlock
ID id-ParentBlock
}

ParentBlock ::= HashPointer
Fig. 4. SignedData SignerInfo series
The syntax of a parentBlock attribute is a value of
type ParentBlock. Type ParentBlock relies on type The e-block header SignerInfo values in the series
HashPointer defined in section 3.1. Type depicted in Fig. 4 can be used for other purposes.
ParentBlock contains two optional components, Their use is specified by a SignedData blockchain
named hash and pointers. In a value of type application. Their use has no affect on the first
ParentBlock, the pointers component must be SignerInfo value, the block header used to create
present. When the message digest of the parent the hash-linked blockchain. The e-block header
block header can be calculated, the hash values can be used to manage a series of
component of type ParentBlock can also be ephemeral sidechains.
included.
An e-block header value can be added to any
5.3 Ephemeral sidechains SignedData container at any time, even after the
block header hash-links have been signed. They
The CMS SignedData message schema can support can be removed without loss of blockchain
multiple content signers through a series of integrity. Though they are part of a SignedData
SignerInfo values. There is one SignerInfo value for container, they are not connected operationally to
each co-signer of the message content or signed the blockchain block header.
attributes. Each SignerInfo value in the series is
independent of all of the others. Each co-signer can E-block headers can be used by an application in a
choose their own signature and hash algorithms, number of ways. They can be used to form a
use their choice of signing key, and include any completely new and independent root block of an
number of attributes of any type of format that ephemeral sidechain, a block not connected in any
they wish. The CMS standard only requires that the way to the SignedData blockchain block header.
contentType and messageDigest attributes also be This could be accomplished by not including any
included, as described in section 3.4. hash pointer back to the parent SignedData block
header in the sidechain e-block header. As an
The SignedData message serves as a container for alternative, the parentBlock attribute described in
the blockchain block header and data components. section 5.2 could be included in the e-block header.
In a SignedData block only the first SignerInfo
value is used as a block header that hash-links the SignedData ephemeral sidechains may be retained
block into the blockchain. The signature on the for as long as needed, but they can be considered
attributes in the block header serves to as being temporary objects. Ephemeral sidechains
cryptographically bind "the contents of the block, a can be deleted from a blockchain once they are no
timestamp, and the previous block header" to form longer needed by the application. This feature can
a chain of data that can provide "a well-defined help SignedData blockchain applications to comply
ordering for transactions" [12]. The SignedData with some aspects of privacy laws and regulations,
block header and the other SignerInfo values in the such as the right-to-be-forgotten requirements of
series are illustrated in Fig. 4. the European Union (EU) General Data Protection
Regulation (GDPR).

6 © International Telecommunication Union, 2018