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

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

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.

"Life is hard, and then you're acquired:-)" wrote:
> 
> 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.

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