Technical component for Certificate authorities

1
for the generation of qualified electronic time-stamps

User and Administration Handbook

AuthentiDate SLM Base

Component V3.0

1
German title of this document referenced in other documents is „Benutzer- und Administrationshandbuch
SLMBC als technische Komponente für ZDAs zur Erzeugung von Zeitstempeln“
© 2005, 2006, 2007 AuthentiDate International AG
Alle Rechte vorbehalten.
Weitergabe und Vervielfältigung nur mit ausdrücklicher Genehmigung durch AuthentiDate.

AuthentiDate International AG
Großenbaumer Weg 6
40472 Düsseldorf / Germany
Tel. +49-(0)211-436989-0
www.authentidate.de info@authentidate.de

--2--
AuthentiDate User and Administration handbook
SLM Base Compo- Technical component for Certificate Authorities
nent V3.0 for the generation of qualified electronic time-stamps

Revision history
Author Date Version Status Comment
Babak Nasri 09.04.2007 0.1 Draft
Stefan Dörpinghaus 10.04.2007 0.2 Draft Minor adoptions
Stefan Dörpinghaus 12.04.2007 0.3 Pre-OR1 Integration of Test Cases;
Correction of incorrect litera-
ture links
Thomas Hetschold 01.10.2007 0.4 Pre-OR1 Textual corrections
Stefan Dörpinghaus 23.11.2007 0.4.1 Pre-OR1 Layout Issues

State of this version

The present version of this document replaces all former document versions which are re-
voked by issuing this document version.

--3--
Table of contents
1 Preface............................................................................................................................ 5
1.1 Composition of this manual ..................................................................................... 5
1.2 Operating conditions................................................................................................ 5
1.3 Authentication .......................................................................................................... 6
1.4 Installation ............................................................................................................... 6
2 Configuration of the SLMBC ZS-ZDA .......................................................................... 7
2.1 Element <httpServer>.............................................................................................. 7
2.2 Element <logging>................................................................................................... 8
2.3 Element <evgLogging>............................................................................................ 9
2.4 Element <license> ................................................................................................... 9
2.5 Element <xmlProtocolHandlerPool>........................................................................ 9
2.5.1 Element <accessAA> .................................................................................... 10
2.5.2 Element <implementationMap> F1SignRequest ........................................... 11
2.6 Element <rfc3161TcpServer>................................................................................ 12
2.7 Element <timeStampingServiceAdaptor>.............................................................. 14
2.8 Element <serialNumberGenerator>....................................................................... 15
2.9 Element <gentimeAndAccuracySource> ............................................................... 17
2.10 Element <signatureModule>.................................................................................. 19
3 SLMBC ZS-ZDA interface............................................................................................ 21
3.1 RFC 3161 TCP interface ....................................................................................... 22
3.2 RFC 3161 error codes ........................................................................................... 22
3.3 PKCS#7 / CMS time-stamps ................................................................................. 22
4 Literature ...................................................................................................................... 24

--4--
 AuthentiDate User and Administration handbook
SLM Base Compo- Technical component for Certificate Authorities
nent V3.0 for the generation of qualified electronic time-stamps

1 Preface

„AuthentiDate Signature Lifecycle Management Base Component“ (brief description

„SLMBC“) is a software module which can be used either as a Signature Application Com-
ponent (SAK2) in accordance with the German signature act (Signaturgesetz (SigG) [1] and
Signaturverordnung (SigV) [2]) for the generation and verification of qualified electronic sig-
natures. More details regarding the SAK mode can be found in the corresponding chapters
of the SLMBC SAK manual [3].

On the other hand, SLMBC can be used alternatively as a technical component for certifi-
cate authorities, complying with German signature act, to generate qualified electronic time-
stamps. However, these functionalities are mutual exclusive. This means that the compo-
nent can not be used in both functions at the same time.

The official title of this document is „SLMBC Technische Komponente für Zertifizierungs-
diensteanbieter zur Erzeugung qualifizierter elektronischer Zeitstempel“. It is referred to with
this title or the acronym of SLMBC ZS-ZDA in other documentations and is directed at ad-
ministrators overseeing the deployment of this document. The administrators should be able
to configure and maintain the component referring to this document.

Important notice: In integration use-cases of SLMBC as the ZS-ZDA all the notices of this
document must be reflected in „Integrator“ documentations and communicated to the end
user. All these relevant notices are highlighted respectively throughout this document for this
purpose.

1.1 Composition of this manual

This document is divided in two chapters: the administration of SLMBC ZS-ZDA by Certifi-
cate Authorities (ZDAs3), and the documentation of the interface which can be used to obtain
time-stamps.

The chapter on the configuration of SLMBC deals with the administration aspects of the
SLMBC documentation. This chapter describes the configuration of SLMBC in detail and
explains what parameters could be adjusted.

The SLMBC interface chapter deals with the software integration aspects of SLMBC in third
party applications.

1.2 Operating conditions4

The target environment and operating conditions of the SLMBC ZS-ZDA is the mass genera-
tion of qualified electronic time-stamps as a technical component of a certificate authority
2
Signaturanwendungskomponente
3
Zertifizierungsdiensteanbieter
4
Einsatzbereich

--5--
holding the proper approval and complying with the German Signature Act. The SLMBC ZS-
ZDA supports different Linux and Windows operating systems.

For the generation of qualified time-stamps several SigG approved secure smart card termi-
nals can be used at the same time.

1.3 Authentication

When generating qualified time-stamps no authentication on the interface level is enforced

of the user or the process using the interface. However as the actual signature generation is
implemented by an internal function of SLMBC ZS-ZDA, the external interface layer does
have identification configuration parameters for internal authentication to access the internal
function of generating the signature.
This information will be used by the internal signature generation function to verify the ac-
cess rights and permission accessing the signature generation tokens5.

The user identification to identify a user (software application) and the user identification to
identify a signature card holder in a group of signature cards are independent from each
other and should not be considered related by any measures.

1.4 Installation

For a general description of the installation of the SLMBC ZS-ZDA please see the separate
SLMBC installation manuals [8] and [9].

After a successful installation of SLMBC following the instructions of the SLMBC installation
manuals [8] and [9] and configuration as SLMBC SAK according to [3], the configuration
instructions given in this document must be followed to transform a SLMBC SAK instance
into a SLMBC ZS-ZDA instance.

5
Signaturerstellungseinheiten

--6--
AuthentiDate User and Administration handbook
SLM Base Compo- Technical component for Certificate Authorities
nent V3.0 for the generation of qualified electronic time-stamps

2 Configuration of the SLMBC ZS-ZDA

The SLMBC ZS-ZDA is configured via XML configuration files. The XML configuration files
are separated into the main configuration file and various auxiliary configuration files.

For a general description of these files please refer to the corresponding chapters of the
SLMBC SAK manual [3].

The following sections describe the XML elements and their content for the usage as a ZS-
ZDA. All configuration is done in the main configuration file.

2.1 Element <httpServer>

The XML element <httpServer> contains the configuration settings for the internal http inter-
face, which will be used by the outer RFC 3161 interface to obtain the signature for a time-
stamp.

For a general description of the element <httpServer> please see the corresponding chapter
of the SLMBC SAK manual [3].

In this chapter of the SLMBC ZS-ZDA manual, only the differences to the general usage are
described, and a general description of the restrictions of the possible configuration ele-
ments is provided. Please note that only the values which should be changed by the admin-
istrator are listed in this chapter. Values of the configuration file, which are not listed here,
are preserved to only be changed upon AuthentiDate approval.

In opposite to the usage of the SLMBC as a SAK, just a single http-listener element is al-
lowed here.

The usage of the https protocol (https listener) is not activated for performance reasons.

An example of a <httpServer> configuration element is given below.

01 <httpServer>
02 <listeners>
03 <httpListener>
04 <hostname>127.0.0.1</hostname>
05 <port>19080</port>
06 <minThreads>5</minThreads>
07 <maxThreads>10</maxThreads>
08 </httpListener>
09 </listeners>
10 <servlet>
11 <name>interface for internal signature creation</name>
12 <httpContext>/xml</httpContext>
13 <servletClass>de.authentidate.module.
14 xmlproto.XmlServlet</servletClass>
15 </servlet>
16 <useDefaultNotFoundHandler>true</useDefaultNotFoundHandler>
17 </httpServer>

--7--
 Line XML-Tag Description
4 hostname The IP address (not the DNS name) of the SLMBC ZS-ZDA; only the
internal signature creation service will be reachable at the configured IP
address.
Important notice: If the signature creation module is located on the
same server as the outer RFC3161 TCP interface, the usage of the value
of “127.0.0.1” is strongly recommended here.
5 port The port at which the internal signature creation service can be reached.
6 minThreads Number of minimal threads, created in advance by the http server to
avoid performance bottle necks. Please note that the number of threads
will be kept in readiness, even if no time-stamps (signatures) are currently
requested.
7 maxThreads Number of maximum threads, created in parallel to serve the time-
stamp / signature creation requests. If the load of the SLMBC TS-ZDA
decreases, the number of thread will be lowered down to the value which
is given in the <minThreads> element. The number of threads should be
related to the number of connected and activated signature creation de-
vices.
13, 14 httpContext Names a relative URL. The internal signature creation module can be
reached through the outer RFC 3161 interface at this URL.
Table 1: Parameters of the XML element <httpServer>

2.2 Element <logging>

The element <logging> holds the logging configuration of the SLMBC ZS-ZDA standard pro-
gram logging. The element <logging> describes, in which detail depth and where log data
are to be written.

For a general description of the element <logging> please see the corresponding chapter of
the SLMBC SAK manual [3].

The recommended log level for the production service of the SLMBC ZS-ZDA is “INFO”.

An example of a valid <logging> configuration element is given here.

01 <logging>
02 <logSinks>
03 <logLevel>INFO</logLevel>
04 <logSink>
05 <logFile>
06 <fileName>log/timestamp.log</fileName>
07 <maxFileSize>10485760</maxFileSize>
08 <oldLogsToKeep>30</oldLogsToKeep>
09 </logFile>
10 </logSink>
11 </logSinks>
12 </logging>

--8--
AuthentiDate User and Administration handbook
SLM Base Compo- Technical component for Certificate Authorities
nent V3.0 for the generation of qualified electronic time-stamps

2.3 Element <evgLogging>

The element <evgLogging> holds the logging configuration of the SLMBC ZS-ZDA logging
(EVG logging). All events described in the security function SF.Auditing can be logged with
the EVG logger (see [4] for further information).

For a general description of the element <evgLogging> please see the corresponding chap-
ter of the SLMBC SAK manual [3].

The recommended log level for the production service of the SLMBC ZS-ZDA is “EVG_2”. An
example of a valid <evgLogging> configuration element is given below.

01 <evgLogging>
02 <logSinks>
03 <customLogSinksType>
04 <logLevel>EVG_2</logLevel>
05 <logSink>
06 <logFile>
07 <fileName>log/toe.log</fileName>
08 <maxFileSize>10485760</maxFileSize>
09 <oldLogsToKeep>30</oldLogsToKeep>
10 </logFile>
11 </logSink>
12 </customLogSinksType>
13 </logSinks>
14 </evgLogging>

2.4 Element <license>

The <license> element specifies the path to the license related files, which are necessary for
the operation of the SLMBC ZS-ZDA.

For a general description of the element <license> please see the corresponding chapter of
the SLMBC SAK manual [3].

An example of a valid <license> configuration element is given below:

01 <license>
02 <licenseFile>config/ts-license.xml</licenseFile>
03 <counterFile>config/ts-counter.xml</counterFile>
04 </license>

2.5 Element <xmlProtocolHandlerPool>

The <xmlProtocolHandlerPool> element contains the settings for the number of pre-
allocated XML parsing factories, the access (authentication and authorization) check of the
internal signature creation service and the “implementation map” elements, which represents
the configuration of the individual functions. When SLMBC is configured to act as a ZS-ZDA,
only the configuration elements of the internal signature creation module are allowed here.

--9--
For a general description of the element <license> please see the corresponding chapter of
the SLMBC SAK manual [3].

An example of a valid part of a <xmlProtocolHandlerPool> configuration element is given

below.

01 <xmlProtocolHandlerPool>
02 <numHandlers>10</numHandlers>
03 <xmlConverterPool>
04 <numberOfInstances>10</numberOfInstances>
05 <namespacePrefixMapperClassName>
06 de.authentidate.sir.NamespacePrefixMapperImpl
07 </namespacePrefixMapperClassName>
08 <contextName>
09 de.authentidate.xml.ns.datastruct.slmbc.functions</contextName>
10 </xmlConverterPool>
11 <xmlProtocolHandler>
12 <maxRequestSize>102400</maxRequestSize>
13 ...

Line XML-Tag Description

2 numHandlers The number of handlers which will accept the signature creation re-
quests from the outer RFC 3161 interface. The number of handlers
should be related to the number of signature creation devices which
are connected to the SLMBC TS-ZDA.
4 numberOfInstances The number of pre-allocated XML parsing factories. This value should
be equal or larger than the value of the <numHandlers> value.
12 maxRequestSize The maximum request size (in bytes) for the SLMBC TS-ZDA XML
interface.
Table 2: Parameters of the XML element <xmlProtocolHandlerPool>

2.5.1 Element <accessAA>

For a general description of the element <accessAA> please see the corresponding chapter
of the SLMBC SAK manual [3].

An example of a valid part of a <accessAA> configuration element is given below.

01 <accessAA>
02 <userAAServiceDef id="accessUaa">
03 <memoryUserAAService>
04 <userAAData>
05 <userId>SLMBC</userId>
06 <secretFingerprint>
07 <hashAlgo>SHA-1</hashAlgo>
08 <hashValue>...</hashValue>
09 </secretFingerprint>
10 <authorization>
11 <thing>F1</thing>
12 <limit> - </limit>
13 </authorization>
14 </userAAData>
15 </memoryUserAAService>
16 </userAAServiceDef>

- - 10 - -
AuthentiDate User and Administration handbook
SLM Base Compo- Technical component for Certificate Authorities
nent V3.0 for the generation of qualified electronic time-stamps

17 </accessAA>

2.5.2 Element <implementationMap> F1SignRequest

For a general description of the element <implementationMap> F1SignRequest please see
the corresponding chapter of the SLMBC SAK manual [3].

Only the XML elements which should be changed by an administrator during the standard
customizing process for a TSA are specified below in the table.

Important notice: The content of all other XML elements should only be changed by – or
under supervision of – an AuthentiDate support professionals.

01 <signingRequestHandlerConfig>
02 <maxSignRetries>2</maxSignRetries>
03 <retryTimeoutMillis>7000</retryTimeoutMillis>
04 <activationMode>immediately</activationMode>
05 <supportedSignAlgo>RSA</supportedSignAlgo>
06 <supportedSignAlgo>SHA1withRSA</supportedSignAlgo>
07 <supportedSignAlgo>RIPEMD160withRSA</supportedSignAlgo>
08 <signingOpLimitations>
09 <activationPeriod>0</activationPeriod>
10 <signatureOpLimitDuringActivationPeriod>
11 0</signatureOpLimitDuringActivationPeriod>
12 </signingOpLimitations>
13 <dynamicConfig>
14 <content>
15 <uriStoredData>file:config/token.xml</uriStoredData>
16 </content>
17 <confirmationSubDir>confirmed</confirmationSubDir>
18 <certPathCertsSubDir>ca-and-root-certs</certPathCertsSubDir>
19 <userAFileName>user.xml</userAFileName>
20 <reconfigPeriod>
21 <metronomeFactoryName>
22 general metronome factory</metronomeFactoryName>
23 <threadName>ConfigWatchdog</threadName>
24 <periodMillis>25000</periodMillis>
25 </reconfigPeriod>
26 <tokenJobWorkerPeriod>
27 <metronomeFactoryName>
28 general metronome factory</metronomeFactoryName>
29 <threadName>TokenJobManager/Worker</threadName>
30 <periodMillis>650</periodMillis>
31 </tokenJobWorkerPeriod>
32 <terminalInitMessage>Geraet gefunden</terminalInitMessage>
33 </dynamicConfig>
34
35 <commonGroupConfig>
36 <unmappedSignerFoundMessage>
37 : keine Gruppe</unmappedSignerFoundMessage>
38 <groupIdDigestAlgo>
39 <algorithmName>SHA-1</algorithmName>
40 <requestedSecurityProvider>BC</requestedSecurityProvider>
41 </groupIdDigestAlgo>
42 </commonGroupConfig>
43

- - 11 - -
44 <ocfConfig>
45 ...
46 </ocfConfig>
47 </signingRequestHandlerConfig>

Line XML-Tag Description

2 maxSignRetries In case of a temporary error in the creation of a signature,
this number specifies the maximum number of attempts to
retry the operation.
3 retryTimeoutMillis Specifies the time interval between two attempts (see row
above) in milliseconds.
5-7 supportedSignAlgo Has to contain the supported signature algorithms of the
SLMBC ZS-ZDA. The value can be provided as an ASN.1
Object Identifier in dotted notation or as a Java algorithm
name. Please note that the encryption algorithm part of
the signature algorithm has to be supported by the signa-
ture creation device (i.e. smartcard).
9 activationPeriod Specifies the activation time of a signature creation device
in seconds after a successful (PIN) authentication. The
special value “0” causes the devices to be activated infi-
nitely.
10-11 signatureOpLimitDuring This value specifies the maximum number of encryption
ActivationPeriod operations of a signature creation device after a success-
ful (PIN) authentication. The special value “0” means that
no upper limit is applied.
24 periodMillis The time period in milliseconds after which the signature
group configuration file is checked for changes.
39 algorithmName The name of the message digest algorithm for the finger-
printing process of the signature groups.
40 requestedSecurity The name of the security provider for the message digest
Provider algorithm for the signature groups.
Table 3: Parameters of the XML element <signingRequestHandlerConfig>

2.6 Element <rfc3161TcpServer>

The XML element <rfc3161TcpServer> contains all configuration settings for the outer
RFC3161 time-stamping interface. Only the direct TCP interface defined in RFC3161 [5] is
supported by the SLMBC ZS-ZDA, while the RFC 3161 HTTP interface is not supported.
Only the direct subordinates of the <rfc3161TcpServer> configuration element are described
in this chapter. The description of the other XML sub-elements is given in the appropriate
chapters.

An example of a valid part of a <rfc3161TcpServer> configuration element is given below.

01 <rfc3161TcpServer>
02 <name>RFC 3161 compliant time-stamping service</name>
03 <hostname>0.0.0.0</hostname>
04 <port>10318</port>
05 <numThreads>5</numThreads>
06 <soTimeoutMillis>5000</soTimeoutMillis>
07 <backlog>2</backlog>
08 <sleepMillisOnOverload>100</sleepMillisOnOverload>

- - 12 - -
AuthentiDate User and Administration handbook
SLM Base Compo- Technical component for Certificate Authorities
nent V3.0 for the generation of qualified electronic time-stamps

09 <maxMessageSize>512</maxMessageSize>
10 <serveJustOneRequestPerConnection>
11 false</serveJustOneRequestPerConnection>
12 <timeStampingServiceAdaptor>
13 ...
14 </timeStampingServiceAdaptor>
15 </rfc3161TcpServer>

Line XML-Tag Description

2 name
3 hostname
4 port
5 numThreads
6 soTimeoutMillis
7 backlog
8 sleepMillisOnOverload
9 maxMessageSize
10-11 serveJustOneRequestPer
Connection
The internal name of the RFC 3161 time-stamping
server. This name has only a descriptive function for
logging purposes, so any chosen value is appropriate
here.
Names the outer RFC 3161 interface IP address of the
SLMBC ZS-ZDA.
The value “0.0.0.0” is recommended here. This value
usually means that the TCP server will accept request
on all local interfaces.
The port at which the external RFC3161 time-stamping
server is listening for RFC3161 compliant time-stamp
requests.
The number of independent TCP request handlers ac-
cepting incoming RFC3161 requests and delegating
them to the responsible worker objects inside the
SLMBC ZS-ZDA. The object pool is initialized during
startup time and remains constant during the lifetime of
an instance of the SLMBC ZS-ZDA.
A numeric value of the timeout period in milliseconds
after which the TCP server socket is closed if no answer
is received from the internal modules.
If the value “0” is configured, no timeout will happen and
the SLMBC ZS-ZDA will never close the socket if no
answer is received. The element is optional.
Important notice: If the element <soTimeoutMillis> is
omitted, zero is taken as default value. It is strongly rec-
ommended to configure a positive value here.
The size of the internal TCP backlog queue which holds
the incoming TCP requests before they are accepted by
the TCP listener. If the backlog queue is filled with re-
quests, the server will return a TCP “connection refused”
error for the next connection.
The time period in milliseconds for which the SLMBC
ZS-ZDA stops accepting any requests if no more free
TCP handlers are available. If the configured value is
too large, the internal backlog queue overflows.
The maximum size of the incoming request in number of
bytes. If the configured value is smaller than the actual
message size, an I/O error is returned to the requestor.
The behavior of the TCP output stream. If this value is
set to “true”, the output stream is closed after a time-
stamp response is written to the stream. The recom-
mended value is “false”.

- - 13 - -
 Line XML-Tag Description
12-14 timeStampingService See chapter 2.7 (Element <timeStampingServiceAdaptor>)
Adaptor
Table 4: Parameters of the XML element <rfc3161TcpServer>

2.7 Element <timeStampingServiceAdaptor>

The XML element <timeStampingServiceAdaptor> is the parent node for all time-stamp re-
lated configuration settings of the SLMBC ZS-ZDA. These elements are a mixture of
RFC3161 related settings and communication and algorithm setting of the SLMBC ZS-ZDA
itself.

Only the direct children of the <timeStampingServiceAdaptor> configuration element are

described in this chapter. The description of the other XML subordinates is given in the ap-
propriate chapters.

An example of a valid configuration element is given below.

01 <timeStampingServiceAdaptor>
02 <ordering>false</ordering>
03 <policy>x.x.x.x.x.x.x</policy>
04 <serialNumberGenerator>
05 ...
06 </serialNumberGenerator>
07 <gentimeAndAccuracySource>
08 ...
09 </gentimeAndAccuracySource>
10 <encryptionAlgorithm>RSA</encryptionAlgorithm>
11 <supportedDigestAlgorithm>SHA-1</supportedDigestAlgorithm>
12 <signatureModule>
13 ...
14 </signatureModule>
15 </timeStampingServiceAdaptor>

Line XML-Tag Description

2 ordering
A flag whether all time-stamps issued by a TSA (one or more
independent instances of the SLMBC ZS-ZDA) should be
ordered directly based on the “genTime” field of the ASN.1
structure. Only the value “false” is allowed here, because:
(1) <gentimeAndAccuracySource> can be configured
with a large value of the <accuracy> element which
makes it impossible to perform such a sorting opera-
tion.
(2) If multiple, independent instances of the SLMBC ZS-
ZD are running in the domain of a TSA, sorting is not
possible, since different <gentimeAndAccuracy-
Source> values can be configured for each instance.
This field is covered in Section 2.4.2 of RFC 3161 [5]:
If the ordering field is missing, or if the ordering
field is present and set to false, then the genTime

- - 14 - -
AuthentiDate User and Administration handbook
SLM Base Compo- Technical component for Certificate Authorities
nent V3.0 for the generation of qualified electronic time-stamps

Line XML-Tag Description

field only indicates the time at which the time-stamp
token has been created by the TSA. In such a case, the
ordering of time-stamp tokens issued by the same TSA or
different TSAs is only possible when the difference
between the genTime of the first time-stamp token and
the genTime of the second time-stamp token is greater
than the sum of the accuracies of the genTime for each
time-stamp token.
If the ordering field is present and set to true, every
time-stamp token from the same TSA can always be or-
dered based on the genTime field, regardless of the
genTime accuracy.
3 policy The value of an ASN.1 Object Identifier which indicates un-
der which policy the time-stamps will be produced by the
TSA.
The value of this field has to be set to an appropriate value.

This field is covered in Section 2.4.2 of RFC 3161 [5]:

The policy field MUST indicate the TSA's policy
under which the response was produced. If a simi-
lar field was present in the TimeStampReq, then
it MUST have the same value, otherwise an error
(unacceptedPolicy) MUST be returned. This policy
MAY include the following types of information
(although this list is certainly not exhaustive):
* The conditions under which the time-stamp token
may be used.
* The availability of a time-stamp token log, to
allow later verification that a time-stamp token
is authentic.
4-6 serialNumber See chapter 0 (Table 5: Parameters of the XML element <time-
Generator StampingServiceAdaptor>
Element <serialNumberGenerator>)
7-9 gentimeAndAccura- See chapter 2.9 (Element <gentimeAndAccuracySource>)
cySource
10 encryptionAlgorithm A name or an ASN.1 Object Identifier of the encryption algo-
rithm used to “sign” the time-stamp responses. The digest
algorithm part of the signature algorithm will be given by the
user as part of the ASN.1 “TimeStampReq” of RFC 3161 [5].
11 supportedDigest A name or an ASN.1 Object Identifier of a message digest
Algorithm algorithm supported by the TSA. Multiple algorithm names
can be given here to widen the spectrum of supported algo-
rithms.
If the user requests a time-stamp with a digest algorithm not
listed as supported algorithm, a RFC 3161 error (badAlg) is
returned. The same exception will be thrown if the “assem-
bled” signature algorithm is not supported by the internal
“F1” function.
12-14 signatureModule
See chapter 0 Table 8: Parameters of the XML element <gen-
timeAndAccuracySource>

Element <signatureModule>
Table 5: Parameters of the XML element <timeStampingServiceAdaptor>

- - 15 - -
2.8 Element <serialNumberGenerator>

The element <serialNumberGenerator> contains the settings for the generation of the serial
numbers for the RFC3161 time-stamps.

All time-stamps conforming to RFC 3161 must include a unique serial number. The SLMBC
ZS-ZDA generates those serial numbers with the help of an algorithm not needing any per-
sistent state. This way it becomes easier to maintain instances of SLMBC ZS-ZDA, espe-
cially because no backup is required.

The serial number generator produces a byte array containing the two's complement binary
representation of an integer value. The byte array is in big-endian byte order: the most sig-
nificant byte is located at index position 0.

The size of the generated byte array is at least 13 bytes, whereas the byte at index position
0 (zero) is fixed to 0x00, so only positive serial number values are generated. The other
twelve bytes are filled with random values generated during the request of a serial number at
run-time. The source of these random numbers is described further below in this chapter.

A byte array can be appended to this “per-serial-number-request” random value to achieve a

fixed length of the resulting number. This byte array is named “highValue”. The length of this
byte array is a configuration parameter of this serial number generator and will be refer-
enced as <bytesForHighValue>.

The algorithm performs the following operations during the startup process of the serial
number generator of the SLMBC ZS-ZDA to create the “highValue”:

First, the secure random algorithm is instantiated by the Java VM. The name of the algo-
rithm itself is the second configuration parameter of the serial number generator.
During the instantiation, the serial number generator is “seeded” with the following values:
• A 64 bit integer containing the UNIX time in milliseconds.
• A 32 bit integer containing the result of the java hashValue method from the concrete
instance of the serial number generator.
• A byte array containing the memory location and the class name of the concrete in-
stance of the serial number generator.

After that, a byte array of the length <bytesForHighValue> is filled with the next random
output of the instantiated and “seeded” secure random algorithm. This value remains un-
changed during the lifetime of a concrete instance of the serial number generator.
With every request of a serial number the following values of the resulting byte array are
used to build the two's complement binary representation of the serial number:

Index in byte array Value Description

0 0x00 Fixed zero value, so the two's complement binary repre-
sentation of the resulting serial number is always positive.
1-4 (four bytes) Serial number counter. This signed Java integer has a
size of four bytes (32 bit) and is incremented every time a
serial number is requested. The start value of this counter
is -2147483648 (-231), the maximum value of the number
can be 2147483647 (231-1). If the range of the 32 bit
signed integer is exceeded, the counter is set to
-2147483648 (-231) again.
5-12 (8 bytes) This value represents the time-stamp at which a serial

- - 16 - -
AuthentiDate User and Administration handbook
SLM Base Compo- Technical component for Certificate Authorities
nent V3.0 for the generation of qualified electronic time-stamps

Index in byte array Value Description

number is to be generated. The value is a 64 bit signed
integer and is set to the local system’s time in milliseconds
since UNIX epoch (0h 1st, January 1970).
13-n (n bytes) The size of “highValue” from the serial number. The
(signed) number size n is a configurable element of the
serial number generator.
Table 6: Composition of the serial number

An example of a valid <serialNumberGenerator> configuration element is given below. A

160 bit (20 bytes) long signed integer value will be created with the serial number generator
configuration below (13 bytes of pseudo random values plus 7 bytes of a “static” random
value).

01 <serialNumberGenerator>
02 <counterWithCurrentTimeMillisAndRandomAsHighValue>
03 <secureRandomAlgorithm>SHA1PRNG</secureRandomAlgorithm>
04 <bytesForHighValue>7</bytesForHighValue>
05 </counterWithCurrentTimeMillisAndRandomAsHighValue>
06 </serialNumberGenerator>

Line XML-Tag Description

3 secureRandomAlgorithm
4 bytesForHighValue
Table 7: Parameters of the XML element <serialNumberGenerator>
The name of the secure random algorithm used. This
secure random algorithm will be instantiated during crea-
tion time of the serial number generator.
If the configured algorithm is not available, a Java Con-
figuration Exception will be thrown during startup time of
the SLMBC ZS-ZDA. The recommended value of this
element is “SHA1PRNG”.
The length of the “highValue” of the serial number. This
high value is created during the instantiation time of the
serial number generator and remains static during the
lifetime of the serial number generator (see above).

2.9 Element <gentimeAndAccuracySource>

The XML element <gentimeAndAccuracySource> is the parent node for all configuration
options regarding the time source for the ASN.1 “genTime” value of the RFC 3161 [5] time-
stamp response or the date time value of the PKCS#7 time-stamp.

When a time-stamp request is sent by a user or an automated process, then the SLMBC ZS-
ZDA sends a NTP message to a configured (S)NTP server waiting for an answer from the
(S)NTP server before the time-stamp is issued by the SLMBC ZS-ZDA.

- - 17 - -
If no date time value can be retrieved from the (S)NTP server, no time-stamp will be issued
by the SLMBC ZS-ZDA and an error message will be sent to the requesting process.

An example of a valid part of a <gentimeAndAccuracySource> configuration element is gi-

ven below.

01 <gentimeAndAccuracySource>
02 <limitDecimalPlacesOfSecondsTo>0</limitDecimalPlacesOfSecondsTo>
03 <blockingNTP>
04 <ntpServer>
05 <host>x.x.x.x</host>
06 <port>123</port>
07 <timeoutMillis>500</timeoutMillis>
08 </ntpServer>
09 <maxAcceptableDispersion>0.450</maxAcceptableDispersion>
10 <maxAgeInMillis>2050000</maxAgeInMillis>
11 <maxStratum>1</maxStratum>
12 <accuracySource>
13 <constantAccuracy>
14 <seconds>1</seconds>
15 <millis>0</millis>
16 </constantAccuracy>
17 </accuracySource>
18 </blockingNTP>
19 </gentimeAndAccuracySource>

Line XML-Tag Description

2 limitDecimalPlaces Section 2.4.2 of RFC 3161 [5] points out that TSAs SHOULD
OfSecondsTo limit the precision of the genTime value (ASN.1 Generalized-
Time) to one second if there is no need to have a fraction bet-
ter than one second.
If this field is set, the genTime field value is limited to the con-
figured number of fractions. Otherwise, the genTime value
(ASN.1 GeneralizedTime) of the returned time-stamps con-
tains all milliseconds of the (S)NTP answer. A value of “0” is
recommended in collaboration with the appropriate “accuracy“
configuration element.
5 host The hostname or IP address of the (S)NTP server.
6 port The port number on which the NTP server is listening. The
element is optional. If it is missing, the default value “123” de-
fined by RFC 2030 [7] is used.
7 timeoutMillis The number of milliseconds the SLMBC ZS-ZDA shall wait at
most for the (S)NTP server to answer the request.
Non-negative values are accepted only. If the value zero is
configured, no timeout will happen but the SLMBC ZS-ZDA will
wait for an answer eternally. The element is optional. If it is not
set, zero is taken as default value.
Important notice: It is recommended to configure a positive
value in any case.
9 maxAcceptable The maximum accepted value of the field “Root Dispersion”
Dispersion within the NTP message received from the (S)NTP server.
This is the value telling about the actual accuracy of the NTP
server’s clock with respect to its reference.
10 maxAgeInMillis The maximum difference given in milliseconds between the
value of the field “Receive Timestamp” minus the value of the

- - 18 - -
AuthentiDate User and Administration handbook
SLM Base Compo- Technical component for Certificate Authorities
nent V3.0 for the generation of qualified electronic time-stamps

Line XML-Tag Description

field “Reference Time” both taken from the NTP message
received from the (S)NTP server.
That difference characterizes how long it has been in the past,
since the NTP server synchronized its clock with its own refer-
ence clock.
11 maxStratum The maximum accepted value of the field “Stratum” within the
NTP message received from the (S)NTP server.
This is the value limiting the level of “directness” for the
(S)NTP server obtaining the time from a reference source.
The lower the values are the more directly the time is obtained.
The element <maxStratum> is optional. The value zero within
an NTP response is special. It means, that the Stratum is not
specified. Responses containing this value are never ac-
cepted, regardless of the presence of the element <maxStra-
tum>.
Thus accepted value for the element range from
1 to 255, both inclusive. A value of “1” is recommended.
14 seconds The second part of the ASN.1 accuracy field of the time-
stamping response.
Please note that the clock of the configured (S)NTP server
must have the configured accuracy (or a lower one).
This field is covered in Section 2.4.2 of RFC 3161 [5].
15 millis The millisecond part of the ASN.1 accuracy field of the time-
stamping response. This field is optional and should be omit-
ted if no meaningful value is set.
Please note, that the clock of the configured (S)NTP server
must have at least this accuracy (or a lower one).
This field is covered in Section 2.4.2 of RFC 3161 [5]:
By adding the accuracy value to the Generalized-
Time, an upper limit of the time at which the time-
stamp token has been created by the TSA can be ob-
tained.
In the same way, by subtracting the accuracy to the
GeneralizedTime, a lower limit of the time at which
the time-stamp token has been created by the TSA
can be obtained.
Accuracy can be decomposed in seconds, milliseconds
(between 1-999) and microseconds (1-999), all ex-
pressed as integer.
When the accuracy optional field is not present,
then the accuracy may be available through other
means, e.g., the TSAPolicyId.
Table 8: Parameters of the XML element <gentimeAndAccuracySource>

- - 19 - -
2.10 Element <signatureModule>

The XML element <signatureModule> contains all needed configuration settings for the ou-
ter RFC3161 interface to access the internal signature module which creates the signature
for the time-stamp with the aid of signing groups.

Only the description of the relevant XML element values, which could be changed by an
administrator, is given below.

Important notice: The content of all other XML elements should only be changed by an
AuthentiDate Support Professional.

An example of a part of a <signatureModule> configuration element is given below.

20 <signatureModule>
21 <httpClientDef id="httpClient1">
22 <url>http://localhost:19080/xml</url>
23 <config>
24 <httpClientConfigDef id="tsCall">
25 <authentication>
26 <httpAuthDef id="auth4tsCall">
27 <basicAuthDef>
28 <userName>SLMBC</userName>
29 <password>123pwadmin@!</password>
30 </basicAuthDef>
31 </httpAuthDef>
32 </authentication>
33 </httpClientConfigDef>
34 </config>
35 </httpClientDef>
36 <xmlConverterPool>
37 <numberOfInstances>5</numberOfInstances>
38 <namespacePrefixMapperClassNa-
me>...</namespacePrefixMapperClassName>
39 <contextName>...</contextName>
40 </xmlConverterPool>
41 <nonceGenerator>
42 ...
43 </nonceGenerator>
44 <signerIdentifier>
45 <signerIdentifier>
46 <groupName>TS#1</groupName>
47 <groupHash>
48 <value>
49 <base64Value>...</base64Value>
50 </value>
51 <algorithm>1.3.14.3.2.26</algorithm>
52 </groupHash>
53 </signerIdentifier>
54 </signerIdentifier>
55 <requestorIdentifier>
56 <requestorIdentifier>
57 <name>dummy</name>
58 <password>123pwdummy@!</password>
59 </requestorIdentifier>
60 </requestorIdentifier>
61 </signatureModule>

- - 20 - -
AuthentiDate User and Administration handbook
SLM Base Compo- Technical component for Certificate Authorities
nent V3.0 for the generation of qualified electronic time-stamps

Line XML-Tag Description

28 userName The username for authenticating the outer RFC3161 layer
against the internal signature module (F1). This username has
to match the userId field of the userAA service (See chapter
“Element <accessAA>”).
29 password The corresponding password for the username defined above.
This message digest of this value has to match the hashValue
of the secretFingerprint field of the userAA service (See chap-
ter “Element <accessAA>”).
37 numberOf In- The number of pre-allocated XML converters. This value
stances MUST be at least equal to the value of the field numThreads of
the rfc3161TcpServer configuration element (See chapter 2.6 -
Element <rfc3161TcpServer>). The recommended value consists
of the value of numThreads plus 1.
49 base64Value The fingerprint (“message digest”) of the signature group which
being used to create the signatures of the time-stamps. This
value can be generated with the help of the “groupFP” graphi-
cal tool.
57 name The name of the user being used to authenticate against the
signing group. This value has to match one of the user names
defined in the “user.xml” file inside the group configuration
folder. (See chapter “2.4 Nebenkonfiguration Gruppen” of [3]).
58 password The corresponding password for the user name defined above.
This message digest of this value has to match the password
fingerprint value of the user which in configured in the
“user.xml” file inside the group configuration folder. (See chap-
ter “2.4 Nebenkonfiguration Gruppen of [3]”).
Table 9: Parameters of the XML element <signatureModule>

- - 21 - -
3 SLMBC ZS-ZDA interface

As described above in the preface of this document, the SLMBC ZS-ZDA has two TCP inter-
faces, an outer RFC3161-compliant TCP interface and an inner HTTP interface.

The outer RFC3161 TCP interface accepts the time-stamping requests, builds the corre-
sponding ASN.1 structure and uses the internal sign function (F1) to create the signature for
the time-stamp with one secure signature creation device of a configured signature group.

Important notice: The user or process requesting time-stamps from the SLMBC ZS-ZDA
must only have access to the outer RFC3161 TCP interface. The administrator has to en-
sure this by using strong passwords and appropriate settings of the firewall.

The description of the internal sign function (F1) including its request and response structure
as well as error responses and all error codes is given in detail in the corresponding chapter
of the SLMBC SAK manual [3]. Therefore, only the outer RFC3161 TCP interface is de-
scribed in this chapter.

3.1 RFC 3161 TCP interface

The details of the TCP-based protocol are given in chapter 3.3 of RFC 3161 [5].

Please note, that only the two direct TCP-based TSA messages “tsaMsg” and “pollReq”
are supported by the SLMBC ZS-ZDA. All other direct TCP-based TSA messages will be
answered with an “errorMsgRep”. The types “tsaMsg”, “pollReq” and “errorMsgRep”
are defined in chapter 3.3 of RFC 3161 [5].

3.2 RFC 3161 error codes

The error codes of RFC 3161 are defined in chapter 2.4.2 of RFC 3161 [5].

3.3 PKCS#7 / CMS time-stamps

RFC 3161 only allows the request of a RFC3161 time-stamp. If the user wishes to receive
an “old” time-stamp which is merely a CMS / PKCS#7 signature container [6] with a signing
time attribute as signed attribute and the message digest of the protected content as signed
attribute, the RFC 3161 protocol cannot be used in a standard way.

However, many customers need to receive this kind of time-stamp. Therefore, AuthentiDate
has extended the usage of a single value of the RFC 3161 ASN.1 structure to allow the re-
quest of RFC 3161 and PKCS#7 / CMS time-stamps with the same protocol: The version
number.

The default value of the version number of the TimeStampReq field as described in RFC
3161 [5] is “one” (1) for this field and RFC 3161 time-stamps will be created if the version
number is set to “one”.
- - 22 - -
AuthentiDate User and Administration handbook
SLM Base Compo- Technical component for Certificate Authorities
nent V3.0 for the generation of qualified electronic time-stamps

If the value “zero” (0) is put into this field, PKCS#7 / CMS time-stamps will be created and
returned to the user by the SLMBC ZS-ZDA.

In this case, all other fields of the TimeStampReq except for the version and mes-
sageImprint field are ignored. The message digest value and the used algorithm of the
messageImprint data are been extracted.

- - 23 - -
4 Literature
[1] Gesetz über Rahmenbedingungen für elektronische Signaturen, 16. Mai 2001,
Stand: Geändert durch Art. 1 G v. 4. 1.2005 I 2
[2] Verordnung zur elektronischen Signatur, 16. November 2001, Stand: Geändert durch
Art. 2 G v. 4. 1.2005 I 2
[3] AuthentiDate SLM Base Component V3.0 Benutzerhandbuch, Version 1.2a,
26. 04. 2007
[4] AuthentiDate SLM Base Component V3.0 Sicherheitsvorgaben, Version 2.8.4,
29. Oktober 2007
[5] RFC 3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP), Au-
gust 2001
[6] PKCS #7: Cryptographic Message Syntax Standard, RSA Laboratories, Version 1.5,
November 1993
[7] RFC 2030: Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI,
Oktober 1996
[8] AuthentiDate SLM Base Component V3.0 Installationshandbuch (Windows), Version
1.0.3, 22. November 2007
[9] AuthentiDate SLM Base Component V3.0 Installationshandbuch (Linux), Version
1.0.4, 22. November 2007

- - 24 - -