Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

[Roland Mueller <roland@xxxxxxxxx>]

Hello Denis,

The ISO working group would like to thank the members of the IETF
working group for their efforts toward producing an interoperable
timestamping standard.  We are pleased to incorporate aspects of the
recent IETF proposal into our work in the interests of developing a
truly interoperable standard.

1. Request message

We concur with the IETF proposal for making the 'mechanism' field of
the interoperable request message an optional field, placed in the
structure at a position selected by the authors of the IETF draft
document.  We feel the selection of a default value for the field is a
matter of local policy and hence should be determined by the local
policy statement of the TSA.

2. Error codes

We concur with the IETF proposal for setting aside a range of error
codes for future use by the SC 27 group.  At this time only one
additional code is anticipated, however setting aside a quantity of
error codes for use by SC 27 is a quite reasonable approach.

3. Reply message

The latest IETF proposal suggests that replies generated by the
systems are quite different, and hence cannot be aligned.  The ISO
working group would respectfully disagree here, as the replies are
actually quite similar, and we believe they can be aligned with a
minimum of effort.

The timestamp information returned by both proposals is actually
identical, as the ISO proposal has chosen to adopt the IETF TSTInfo
structure, with an optional mechanism field corresponding to the one
agreed to above.  Since both proposals use the same TSTInfo structure,
time values are interoperable, hash codes and algorithms are
interoperable, policy and mechanism identifiers are interoperable.
Both proposals encapsulate the TSTInfo structure in the TimeStampToken
datatype; the only remaining difference is in syntax of that datatype.

The IETF draft defines the TimeStampToken datatype as a CMS SignedData
construct, where the TSTInfo structure is wrapped inside the CMS
structure.  CMS SignedData constructs can be used in two different
ways, however; as an encapsulation and as an external signature.  The
encapsulation mode means the data upon which the signature is computed
is wrapped inside the CMS structure, whereas the external signature
mode leaves the data external to the CMS structure.  Both modes provide
equivalent security, both are directly supported and specified within
the CMS specification [RFC 2630, page 9].

The ISO proposal is to simply use the CMS construct as an external
signature rather than as an encapsulation.  The ISO proposal thus
defines the 'TimeStampToken' data type as follows:

TimeStampToken ::= SEQUENCE {
        tspData         TSTInfo,
        tspSignature    OCTET STRING }

The CMS SignedData construct used as an external signature is
DER-encoded in the tspSignature field.  In effect both proposals
accomplish the same thing; the TSTInfo structure is signed, and the
signature information is encapsulated in a CMS SignedData construct.

Defining the TimeStampToken type as proposed above allows both IETF
and ISO mechanisms to generate fully interoperable tokens, while in
addition allows the ISO to develop those additional mechanisms it
has identified for support.

On a final note, aligning the standards as proposed above has the
added benefit of making the token embedding technique detailed in
Annex A of the IETF draft also completely interoperable.  No changes
to that Annex are required.
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