[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IETF and ISO alignment on Time Stamping
"...primarily intended for something else..."?
The policy IMHO is specifically used by the client to specify a particular
variant of a general service, provided by the server. Generating ISO or
IETF-flavored token is precisely a variant of a general service.
A server can use a policy, or a combination of a policy and a policy
qualifier. I personally would favor using a qualifier with a policy, like
id_timestamp-body-ISO and id_timestamp-body-IETF.
Example:
A TSA Server declares: Policy X.Y.Z will generate a timestamp with the most
precise timing information I have. Use the qualifier id-timestamp-body-ISO
to obtain the ISO-formed response, and the id_timestamp-body-IETF otherwise.
Defaults... Hmm. If no policy (and no qualifiers, therefore) are defined in
the request, the TSA should use the default policy (of course) and IETF
wrapping of the response. But I can compromise here :).
Michael
> -----Original Message-----
> From: Roland Mueller [mailto:roland@tuvit.net]
> Sent: Thursday, January 27, 2000 1:21 PM
> To: Michael Zolotarev
> Cc: PKIX mailing group
> Subject: 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
> > >
>