IETF and ISO alignment on Time Stamping

[Roland Mueller <roland@xxxxxxxxx>]

I write to the PKIX working group as the editor of the ISO working draft
on time stamping. ISO SC27 has begun work on an International Standard
on time stamping (ISO Working Draft 18014) in 1998.  The ISO SC27 WG2
adhoc group on time stamping met recently and discussed the differences
between the IETF draft and ISO WD 18014, especially with respect to data
structures, and came to the following conclusions.

The apporach of WD 18014 has been to be compatible with the IETF PKIX
working 
group's Time Stamp Protocol document. It is understood that the PKIX
approach 
focuses on digital signatures as the means to bind information within
time stamp 
tokens. The motivation for the protocol is well understood. The SC 27
WG2 group 
has always attempted to align their work as much as possible with the
respective 
valid IETF drafts.

However, the members of the ISO SC27 WG2 adhoc group have taken a
broader and 
more generic approach to accommodate the diversity of time stamp
mechanisms that 
exist within the community. This includes the standardization of other 
mechanisms beyond the particular mechnisms to be standardised by the
PKIX 
working group. 

Therefore the WG2 adhoc group would like to offer the following proposal
to the 
PKIX working group to solve the interoperability issues present. It is 
understood that this proposal reaches the IETF working group at an
extremely 
late stage in its standardisation cycle. Even at this late time the SC27
WG2 
adhoc group feels that it is important to achieve interoperability. It
is also 
realised that the adoption of this proposal may cause a delay in the
IETF 
process. However, the PKIX working group may consider whether the issue
of 
interoperability is more important than the timeliness of the document.

The ISO SC27 WG adhoc group's proposal can be characterised in the
following clause.


IETF - ISO Interoperability
---------------------------

Summary
-------

To achieve interoperability between ISO and IETF proposed standards,
the ISO has adjusted its messages and tokens in order to align as
closely as possible with the IETF standard, while still serving the
diverse interests of the group.  The following summarizes the
remaining areas to be resolved between the two standards, along with
an exact specification of the proposed changes.

1. Add one field in TimeStampReq and TSTInfo
2. Add one additional error code
3. Adjust encapsulation of TimeStampToken


Detail
------

1. TimeStampReq, TSTInfo

The ISO has adjusted its timestamp request message and timestamp info
structures to be compatible with the corresponding IETF structures,
with the addition of a single "mechanism" field.  This field
identifies which mechanism is used to form the timestamp token, either
the IETF mechanism or any of the proposed ISO mechanisms.  In the IETF
standard, only the IETF mechanism would need be recognized.  The field
contains an OID identifying the timestamping mechanism, and is added
to the structures as follows:

MechanismIdentifier ::= OBJECT IDENTIFIER

TimeStampReq ::= SEQUENCE {
	...
	messageImprint	MessageImprint,
	mechanism	MechanismIdentifier,  -- addition
	...
}

TSTInfo ::= SEQUENCE {
	...
	policy		PolicyInformtion,
	mechanism 	MechanismIdentifier,  -- addition
	...
}

An OID would also be allocated for use in identifying the IETF
mechanism.

2. PKIFailureInfo

If the TSA does not support the requested mechanism it returns an
error code in the "status" field of the TimeStampResp message.  A new
error code is added to PKIFailureInfo to support this, as follows:

PKIFailureInfo ::= BITSTRING {
	...
	mechanismNotSupported (18),  -- addition
	-- the TSA does not support the requested mechanism.
}

3. TimeStampToken

The ISO has modified its timestamp token structure to interoperate
with the IETF token, with an adjustment to the specified
encapsulation.  The ISO supports alternate token encapsulations and
hence defines the token more abstractly.  The IETF mechanism will
continue to use the specified SignedData construct [CMS], encoded as
an external signature (RFC 2630 pp. 9) in the signatureInfo field
below: 

TSTSignature ::= OCTET STRING

TimeStampToken ::= SEQUENCE {
        tokenInfo       TSTInfo,
        signatureInfo   TSTSignature OPTIONAL  -- SignedData,
DER-encoded as
                                               -- external signature
}

The signature is computed on the TSTInfo structure as before, and the
signature data is inserted in a SignedData construct.  The construct
is then encoded in the signatureInfo field as an external signature
(RFC 2630, pp. 9).  The existing content type identifier is retained.

Greetings

Roland
begin:vcard 
n:Mueller;Roland
tel;fax:(512) 795-0495
tel;work:(512) 795-0494
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:roland@tuvit.net
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard