Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt (Re: Protocol)

From: Robert Zuccherato <[email-masked]>
Date: Thu, 13 May 1999 10:27:47 -0400

Michael;

The issue of billing has been discussed previously (at least at the Los
Angeles meeting).  At the time we decided that we would not introduce
additional requirements into this document to accommodate billing, if those
requirements conflicted with some of the stated goals of this protocol (for
example, that the requester not be verified by the TSA).  While billing is a
real concern, and in order to do so, the requester will have to be
identified, that should be done outside of the protocol defined by this
document.

That is why we say:
"In situations where the TSA requires the identity of the requesting entity,

it is suggested that alternate identification means be used (e.g. CMS 
encapsulation [CMS] or TLS authentication [RFC2246])."
That is also one of the reasons that no particular transport mechanism
described is mandated by this draft.  

	Robert.

> ----------
> From: 	Michael Zolotarev[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Wednesday, May 12, 1999 10:02 PM
> To: 	'Robert Zuccherato'; 'PKIX mailing group'
> Subject: 	RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt (Re:
> Protocol)
> 
> Robert,
> You wrote:
> >I am hesitant to require the extra layer when it isn't really required.
> The
> >PKIHeader would serve no purpose here.
> 
> I can see one apparent need for having something more in the protocol
> frame
> then just Length,Flag,<TST structure>. That is, the originator info.
> Otherwise, billing becomes a real problem.
> CMP format would solve it by specifying the Sender in the header and
> signing
> the whole lot ( so nobody can send a request on somebody else's behalf).
> Or
> just a signature may suffice, as a minimum.
> 
> To me, billing alone can justify having more complex structure.
> 
> Regards
> MichaelZ
>