Subject: Comments on time-stamp-01: Use of PolicyInformation

From: [email-masked] (Terry Hayes)
Date: Mon, 24 May 1999 11:56:27 -0700

I have some questions/comments on the use of PolicyInformation in the
proposed time-stamping protocol.

First, a PolicyInformation field is required in the TSTInfo (response)
data structure, but no standard policy OID is defined by this draft.  To
allow interoperability, there should be at least one standard OID
defined (with appropriate definition, see following).  An alternative to
this is to make the policy field in the response optional.  This would
indicate that the response is delivered under some standard (minimum)
policy, or that the policy is as agreed between the client (or CA) and
the TSA.

Second, the draft needs to indicate (or suggest) what types of
information (guarantees?) are carried by the policy.  I can think of
several:

   * indicate method used to define valid message imprint digests.  The
     TSA would be guaranteeing that the digest was considered usable at
     the time of the time-stamp.
   * indicate the availability of a time-stamp log, to allow later
     verification that a time-stamp token is authentic.
   * indicate certification of the timestamp accuracy (by some third
     party?)

Since there is no discussion in the draft on what the "policy" field
might represent, it will be difficult to build interoperable clients and
servers.  I suggest that a standard OID should indicate:

   * The TSA checks digests against a current list of acceptable digests
     defined by RFC/standard - either the time-stamp document itself, or
     a separate document that is updated to follow the latest
     technology.
   * A qualifier indicates whether the TSA logs time-stamps and can
     provide access to logs if needed for arbitration purposes.

Third, I believe that the authors assume that clients perform validation
of the TSA certificate chain using the appropriate policy value.  This
is standard X.509 processing.  However, it would be better to state the
requirement (briefly) in the time-stamp draft.

---

From: Robert Zuccherato <[email-masked]>
Date: Tue, 25 May 1999 15:31:46 -0400

Terry;

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Tuesday, May 25, 1999 2:54 PM
> To: 	Robert Zuccherato
> Cc: 	[email-masked]
> Subject: 	Re: Comments on time-stamp-01: Use of PolicyInformation
> 
> I think the field should be marked optional.  An alternative would be to
> allow
> the client to ignore the value in the policy field.  If this is already
> intended
> (I can't find text that says the client needs to process the policy
> value), then
> text needs to be added to make that clear.
> 
Yes, this should have been made more clear.  How about if I add text similar
to the following:

The client application SHOULD check the policy field to determine whether or
not the policy under which the token was issued is acceptable for the
application.  The client MAY ignore this field if that is acceptable for the
intended application.

> A short list of issues that should be covered by policy would be good.  I
> think
> it would help people understand why the policy field is present, and what
> kinds
> of things are not covered by the protocol definition itself.  (Is my list
> at all
> close?)
> 
Yes, I will use your short list as a minimal set of issues that should be
covered by policy.

	Robert.

> Robert Zuccherato wrote:
> 
> > I would agree that the issue of time stamping policy and time stamping
> > practice statements are important ones that will need to be solved for
> > interoperability.  However, I really don't think that including
> descriptions
> > of policies and practice statements within this draft is a good idea.
> For
> > this issue to be addressed properly, a document similar to RFC 2527
> should
> > be produced for TSAs.  I could include a short list suggesting some of
> the
> > issues that should be covered by a TSAs policy.
> >
> > Regarding the definition of a standard policy OID in this document.  I
> think
> > that coming to agreement on the meaning of such an OID would be a
> challenge
> > and that in the end it would be an OID that basically meant nothing.  I
> > don't think that we even define a default certificate policy OID in
> PKIX.
> >
> > > ----------
> > > From:         [email-masked][SMTP:[email-masked]]
> > > Reply To:     [email-masked]
> > > Sent:         Monday, May 24, 1999 2:56 PM
> > > To:   [email-masked]
> > > Subject:      Comments on time-stamp-01: Use of PolicyInformation
> > >
> > > <<File: thayes.vcf>>