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

From: Robert Zuccherato <[email-masked]>
Date: Tue, 25 May 1999 14:12:17 -0400

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>>
> 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: [email-masked] (Terry Hayes)
Date: Tue, 25 May 1999 11:54:04 -0700

Robert,

It is true that PKIX doesn't define a default certificate policy OID.  However
it also does not REQUIRE that an OID is used in certificates.  Yes, many
deployments of PKIX will use them, but it is not required to generate valid
certificates.  The draft timestamping protocol REQUIRES a policy OID in the
TSTInfo sequence.  Since you don't provide one, every implementation will define
their own, and basic interoperability will be nonexistent.

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.

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?)

Terry

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 May 1999 14:55:58 -0400

Robert,

I agree that we do not need to have at least one policy defined before we
can move forward.  The imnportant part, for the synatx that we are defining
here, is that we have a placeholder defined for a policy OID, and a brief
discussion of the need for a relying party to be able to examine the OID to
determine if it is acceptable for the time stamp application in question.

Steve