RE: IETF and ISO alignment on Time Stamping

[Michael Zolotarev <mzolotarev@xxxxxxxxxxxxx>]

The current timestamping draft defines the Policy field in the request
message. I believe it can be successfully used instead of introducing the
MechanismIdentifier field.

Michael

> -----Original Message-----
> From: Roland Mueller [mailto:roland@tuvit.net]
> Sent: Thursday, January 27, 2000 6:52 AM
> 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
> 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
>