RE: IETF and ISO alignment on Time Stamping

["pat cain" <pcain@xxxxxxx>]

Roland,
Since I'm only one of the four authors of the time-stamp draft you may get
different responses from the other authors, but here's my cut:  (portions
that I am not replying to were snipped out)

> -----Original Message-----
> From: Roland Mueller [mailto:roland@tuvit.net]
> Sent: Wednesday, January 26, 2000 2:52 PM
> To: IETF-PKIX
> Cc: Zuccherato, Robert; Manas, Jose A.; Matyas, Mike; Quisquater,
> Jean-Jaques; Haber, Stuart; Doonan, Wes; Lai, Xuejia; Chawrun, Mike
> Subject: IETF and ISO alignment on Time Stamping
>
> 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
...

pc> I always worry when an "ad hoc" group sends in comments....

>
> IETF - ISO Interoperability
> ---------------------------
> 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.
>

pc> The current messageImprint object is an AlgorithmIdentifier followed by
a value. The messageImprint object is included within the TimeStampReq and
the TimeInfo. In many cases we expect that this will be a hash-OID followed
by a hash value. In some cases it may be a cryptographically different
combination (we may have erred in the use of the word hash, but it's only an
identifier so anything we pick will be wrong to someone). I expect that you
would use the existing AlgorithmIdentifier to state your "mechanism", no? We
spent a good chunk of time trying not to cryptographically specify how one
would have to "timestamp" as we all expect that the mechanisms used to
securely perform the "stamping" will change over time. (And some of the good
mechanisms are patented/encumbered.)

> 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.
> }
>

pc> I was expecting the use of "0 {Bad Alg}" myself. Maybe we should make
this more clear.

> 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.
>

pc> I'm lost on two points, here. 1. Although we currently require the use
of a CMS object as the TimeStampToken, we have not seen any requests for
other formats* in the three years of development of the draft. ( *= we
debated the CMP vs CMS encapsulation at one point). At this late stage I'm
not interested in adding a new format unless a specific problem is
identified. The IETF historically has not left a hole to be filled in later,
as this wrecks interoperability.
2. If the ISO and the IETF standards are expecting to interoperate totally,
why do we need the ISO one?

Pat