[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IETF and ISO alignment on Time Stamping
Michael,
you are right but taking into account that there are other mechanisms
then this way would be cleaner and not a way of using a field that's
primarily intended for something else.
Roland
Michael Zolotarev wrote:
>
> 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
> >
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