Subject: Re: draft-ietf-pkix-time-stamp-01.txt comments

From: Peter Sylvester <[email-masked]>
Date: Wed, 12 May 1999 19:28:33 +0200

> 
> The need for the tag is also specific to the use models. Here again, what is
> being attempted here - to audit who is doing what and to whom? For what
> purpose?
Right, that seems to be the question.
> 
> >
> > For example if one uses an e-mail based service, the request would
> > probably have a message-id in the header and the response may use
> > an in-reply-to or references.
> 
> I agree a tag is necessary to identify the applications, how ever I would
> like to see something larger than a tag. Say I want to authenticate, end to
> end, that a particular application sent the logging server a message for
> logging. I would want  to store a branding token from the app itself in the
> timestamp structure to support identifying which app and which specific
> instance of it did the deed.
> 
> Here again the missing piece would be a standard way of watermarking  or
> branding executables so that they could identify themselves. My feeling is
> that this is a much bigger issue than people think.
I don't think that AUTHENTICATION is the demand. The demand seems to be
to simplify the implementation of a kind 'high level datagram oriented'
protocol, where the process that issues the request does not immediately
receive a response on a full duplex channel, AND it may be somewhat 
difficult to associate the response to the request. In any case, I do not
see a need for some 'tag' inside the signed portion of the response. 

> 
> >In the ftp case you may need a
> > convention what filenames to use.
> >
> > Comment2: The sequence number is use when you want a
> >
> >  "strictly monotonically increasing Integer from one TimeStampToken
> >   XXXXXXXX
> >  to the next."
> >
> > If you don't have a sequence number, you don't have "strictly".
> >
> > There is no need to always provide unique time stamps for certain
> > types of service. The 'stamps' from a real postal service are
> > within a precision of half an hour or even less for example.
> 
> Peter, pardon my reply here, but this comment is both out of context,
> generally wrong, and irrelevent to commercial timestamping.
> 
> If you are trying to create a postal processing system, wherein you only see
> (or contact) the postal agent once a day, then the issue of the
> date/timestamp may be OK. But by the way, the actuality of when you deposit
> mail with the post office and when it is stamped is also a mystery in most
> instances, except to say, that the mail will be cancled when it is
> processed, and that is the time that it will have stamped on it. So in
> reality, unless the mail is hand canceled, what you get stamped on the mail,
> is the "when they got around to it" time which in most instance is within 24
> hrs of depositing the mail with "them".
Aren't you just confirming what I had said?  The time stamp that you received
for a registered mail is not necessarily a UNIQUE value.

Why is this comment out of context? My context was to try to explain
why sequence number may be optional and not required for all services.
The weak precision of real postal service time stamps 
is only an illustration of a situation where unique time stamps do not occur
when you just county seconds or minutes or whatever. There are time stamping
services that include strict sequencing (so you could use them to solve
problems about who did something before someone else.)

But for example to get a time stamp to indicate that
I have filed early enough my tax declaration, neither me nor the
verifying cares whether the time stamps are unique. The stamps are
recognised by both parties as being the authoritive indication of 
some time, not more.

> > Comment4: Why just 8 bits signed integer for a precision. The encoding
> >           is just an integer.
> >           The fractionofSecond definition is not quite nice for
> >           a display. A power of 10 seems more appropriate. In fact
> >           I do not see at all why it should be an integer: The
> >           genTime is a STRING, thus fractionOfSecond would probably
> >           better be a NumericalString, so a display may simply
> >           concatenate   genTime '.' franctionOfSecond
> 
> My feeling is that *any* timestamp structure MUST be able to support time
> resolution into the MicroSeconds, and if the Draft McNeil and I are about to
> send, you will see we have done just this. AQlso the structure should be
> totally binary in nature. The who of who is using it is a computer, so keep
> it digital.
Human beings don't think in binary terms.
Or, then generaltime should also be a binary? 

Time stamping is something else than providing a good value of time. ??

> >           Whether the precision is really needed in this case is
> >           another matter. Shouldn't it be optional?
> 
> No, the precision of the stamp structure is part of what's being
> standardized and so it should be fixed, IMHO.

Where is this roadmap defined? IMHO the time stamping text does not
necessarily define a trustworthy replacement of an NTP protocol. 
If one can have a protocol that can handle that, why not, but that's 
not all.  

Regards
P

---

From: Robert Zuccherato <[email-masked]>
Date: Wed, 12 May 1999 13:24:58 -0400

Peter;

My comments are below.

> ----------
> From: 	Peter Sylvester[SMTP:[email-masked]]
> Sent: 	Wednesday, May 12, 1999 4:54 AM
> To: 	[email-masked]
> Subject: 	draft-ietf-pkix-time-stamp-01.txt comments
> 
Given that some people did not want any precision at all.  I think that 8
bits is a good compromise.

>           another matter. Shouldn't it be optional?
If you do not want any greater precision than that offered by
GeneralizedTime, you can put a 1 value in fractionOfSecond and 0 in
precision.  Thus, no one is forced to use greater precision than they want.
>              
> 2.1. Requirements of the TSA
> 
> The TSA is REQUIRED:
>      1. to provide a trusted source of time.
>                      trustworthy ?? 
> 
Either is fine with me.

>      2. not to include any identification of the requesting entity in 
>         the time stamp token.
> 
>      3. to include a monotonically incrementing value of the time of day 
>         into its time stamp token.
>                             tokens.      
> 
Sure.

>      4. to produce a time stamp token upon receiving a valid request 
>         from the requester.
> What does this mean if the TSA can ignore the request due to overrun?
> See security section 4.5 ??
> 
I don't see a conflict.  But to make things more clear, how about:
4. to produce a time stamp token upon receiving a valid request 
        from the requester, when this is possible.

>      5. to include within each time stamp token an identifier to 
>         uniquely indicate the trust and validation policy under which
>         the token was created.
> The policy is optional, isn't it?
> 
No, it is not optional in TSTInfo.

>      6. to only time stamp a hash representation of the datum, i.e. a
>         data imprint associated with a one-way collision resistant hash-
>         function OID.
> 
>      7. to examine the OID of the one-way collision resistant hash-
>         function and to verify that this function is "sufficient" (see
>         Section 2.4). 
> The text later on does not specify what kind of error should be returned.
> Shouldn't there be an error code in the PKIFailureInfo? Or is this
> badAlg or badRequest ?
> 
I was under the impression that badAlg would cover that.

>      8. not to examine the imprint being time stamped in any way. 
> What does THAT mean? If you keep a log of requests/tokens, are you
> 'examining' the request?  
> 
No, I wouldn't think that keeping a log would constitute "examining" the
request.  This requirement simply means that the TSA cannot attempt to
determine any information about the message from the imprint, that may
inadvertently leak out.
>     
>      9. to sign each time stamp token using a key generated exclusively 
>         for this purpose and have this property of the key indicated on 
>         the corresponding certificate.
> 
>     10. to include supplementary temporal information in the time stamp 
>         token (from TDA's) if asked by the requester.  If this is not 
>         possible, the TSA shall respond with an error message.
> Would it be possible to respond with a 'modified answer' 
> and simply not including the missing TDAs in the token.
> The application could decide how to interprete the result? I don't really
> care.  
> 
It is possible to do that now, I believe.  The TSA could respond with
PKIStatus having value (1) grantedWithMods, which is an error message, and
not include the missing TDAs.

>     11. to provide a signed receipt (i.e. in the form of an 
>         appropriately defined time stamp token) to the requester, where 
>         appropriate, as defined by policy.
> 
> The definition of TSTTime (or TSTInfo) does not say what should
> put as time in case of a PKIStatus rejected especially when
> 
>     timeNotAvailable {14},
>       -- the TSAs time source is not available
> 
Actually, we say:
"When issuing an error response with PKIFailureInfo having value 
timeNotAvailable (14) then the TSA MAY place any value (e.g. a random 
value, the closest approximation available, or a fixed value) in the 
tstTime field of TSTInfo.  Upon receiving such an error response a 
client MUST not trust the time contained in the tstTime field."

> A small wording change in the following:
> 
>      6. A CA shall normally conduct a test for proof of possession for 
>         each user's signing private key (including the TSA/TDA signing 
>         private key). However, in some environments, the CA might not 
>         perform a proof-of-possession of the private key when issuing 
>         certificates. In these instances, in order to prevent certain
>         attacks and to properly check the validity of the binding 
>         between an end entity and a key pair, a certificate identifier 
>         of the TSA/TDA shall be included as a signed attribute.
> 
>                                               the signature MUST contain
>         an ESSCertID authenticated attribute.
> 
> see also the wording in:
> 
> certificate that is to be used to verify the token.  This field MAY be 
> omitted if the Signing Certificate Attribute has been included as a 
> signed attribute.  (See Section 5 of [ESS].)  It MUST be present if the 
> ESSCertID Attribute is not used to identify the TSA.
> 
Fair enough.

> The socket based protocol does not seem to follow the requirements
> of not giving non signed responses.
> 
Actually, we say a response "is or includes a TimeStampToken".  So the
unsigned messages within the socket based protocol do not contradict this
requirement.
>  
> In fact, there seems to be some confusion in layers. What is considered
> as 'not respond' in a context of http for example. You cut the
> connection? You just let the connection time out? 
> 
>         produce a valid response before responding, if this is possible.  
>         If this is not possible, it MUST ignore the requests and not 
>                                     ????????????????????????????????
>         respond.
>         ???????
> 
> It seems to me that the socket based protocol is basically designed
> as an internal protocol among a front end transaction based http 
> and a back end signing entity for example, thus operated in a different
> security context; no problem with that. 
> 
> In general I guess it is necessary to make a precise definition what means
> 'returning a response', 'not returning a response' depending on each
> lower layer, especially for http, 'document contains no data' = 0 length
> response or time out.  
> 
See comment above.

> > A simple MIME object is specified as follows.
> 
> >    Content-Type: application/timestamp
> >   Content-Transfer-Encoding: base64
> 
> >   <<the ASN.1 DER-encoded Time Stamp message, base64-encoded>>
> No: An appropriate, content preserving transfer encoding should be used.
> Someone can reencode in quoted-printable or whatever. 
> 
> Which method should be used in http to send a request. 
> (POST ??) PUT?? Don't care?? 
> 
I don't really have an opinion about these.  If someone with a strong
opinion wants to suggest something, that would be fine.

> > This MIME object can be sent and received using common HTTP processing
> > engines over WWW links and provides a simple browser-server transport
>                                                CLIENT
> > for Time Stamp messages.
> 
>      1. When there is a reason to believe that the TSA/TDA can no longer
>         be trusted, the authority's certificate MUST be revoked and 
>         placed on the appropriate CRL.  Thus, at any future time the 
>         tokens signed with the corresponding key will not be valid.
> 
> Tokens with a time superior than the end of validity are not valid.
> 
I would think not.

> And telling HOW a ca should act should not be the business of this
> text. There might be OCSP for example.
> 
True.  I will modify the sentence to not prejudice any particular revocation
method.

> It seems that a paragraph about configuration is missing:
> 
> - what URI should be used?
> - How do I get a trustworthy certificate
> 
> One suggestion that minimises the two parameters into one:
> 
> A certificate of a TSA/TDA may contain an AIA with 
> id-kp-temporalDataAuthority and an URL. 
> 
> and to say that it is a local matter of an application to decide
> which time stamp service is 'trustworthy'. 
> 
This is probably a good idea.

> Appendix A:
> 
> For this purpose, we define a PKCS #9 [PKCS9] time stamp token attribute 
> type.  This attribute type specifies the time stamp token, which MUST be 
>                                                                  can
> included as a signed attribute of the SignedData object. 
> 
Sure.

Thanks for your comments.

	Robert.