Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

From: "Life is hard, and then you die." <[email-masked]>
Date: Fri, 11 Feb 2000 10:14:15 -0800 (PST)

I'm probably a bit late for this, but here goes anyway. I have two
comments, one related to the failure-info bits, one related to the
transport mechanisms.

1) I'm somewhat unhappy with allocation of values in the
   PKIFailureInfo definition. Either don't even try to be compatible
   with CMP (i.e.  just use 0, 1, 2, etc), or then use a different
   space (e.g. 100, 101, etc). With the current definition the codes
   conflict with or are intermingled with CMP defined values (it might
   be a good idea to set a IANA registry for these values, or maybe
   not).

2) The transports are basically the same as 2510, which have been
   shown to have problems. Two things specifically:

   A) Is polling needed at all? If so, why doesn't the http transport
      allow for polling? Either both socket and http should define it,
      or neither, as they both have similar semantics. Also, if
      polling is indeed to be supported, some mechanism for connection
      keep-alive signalling in the socket protocol is needed.
      Actually, keep-alive signalling might be useful if applications
      have whole bunches of documents they want timestamped.

   B) What is the partialMsgRep in the socket protocol good for? The
      request message contains only single request, and the response
      message contains a single structure which I don't see how and
      why you would split up.

   Because I'm not really sure polling makes much sense here, the
   easiest things might be to define the socket protocol as just
   tsaMsg, finalMsgRep, and errorMsgRep, or even just the raw DER
   encoded message as is done for HTTP (since it's DER encoded the
   length is available in the first few bytes). Alternatively, reusing
   the new transports from CMP would allow some folks to reuse
   existing code (at the expense of extra work for those implementing
   just TSP) and provide keep-alive signalling for the socket
   protocol.

  Cheers,

  Ronald

P.S. Minor typo's: "Æ" is used (character 0xC6) instead of "'" in various
     places.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Feb 2000 22:43:32 +0000

Denis, Ronald,

I agree we should align these. However, there's an upcoming 
rev. of CMP (currently being tweaked on the ca-talk list by the
folks who've done the interop), so we do have the option
of adding the TSP values into CMP and moving the colliding
ones. Alternatively, we could add "ranges" into CMP
(not v. extensible though & it wastes bits). I don't
mind which way we do this, but we do need to get rid of
the collisions (and hopefully, prevent future collisions).
Either way, I reckon TSP can stick with its values and CMP can
change.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com