[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on RFC3161
Alfonso,
> Hi Everyone,
>
> In my opinion, in a future rfc3161 update, the following parts should
> be corrected .
Since RFC 3161 has just been issued in August 2001, it will not be re-issued
shortly.
> Comment A
> There is an inconsistency between these statements present in section 1:
> - "It also establishes several security-relevant requirements for TSA
> operation, with regards to processing requests to generate responses"
> - "This standard does not establish overall security requirements for
> TSA operation, just like other PKIX standards do not establish such
> requirements for CA operation"
This is not inconsistent: "several security-relevant requirements" is
different from "overall security requirements".
> Comment B
> There should be no ambiguity (neither minor) in the scope of TSP.
>
> In my opinion, it's preferable to say that "The TSA is a TTP that
> creates time-stamp tokens in order to indicate that a datum existed
> _at_ a particular point in time", according to section 2.
> And should be avoided to say that "A time-stamping service supports
> assertions of proof that a datum existed _before_ a particular time",
> as stated several times in section 1.
No. This point has been discussed on the pkix mailing list and the current
text reflects the concensus reached.
> It's part of the verification phase to understand if a token is subsequent
> or antecedent to another one.
> Comment C
> The part of section 2.4.2:
>
> rfc3161> In such a case, the ordering of time-stamp tokens issued by
> rfc3161> the same TSA or different TSAs is only possible when the
> rfc3161> difference between the genTime of the first time-stamp token
> rfc3161> and the genTime of the second time-stamp token is greater than
> rfc3161> the sum of the accuracies of the genTime for each time-stamp token.
>
> should be replaced with:
> In such a case, the ordering of time-stamp tokens issued by
> the same TSA or different TSAs is only possible when the absolute value
> difference between the genTime of the first time-stamp token
> and the genTime of the second time-stamp token is greater than
> the sum of the accuracies of the genTime for each time-stamp token.
It is implicit that such comparisons are made between TSA servers that are
trusted and compliant with the requirements. So adding the word "absolute"
is not necessary in that context.
> In fact, when a TSA clock drift outside the declared accuracy
Hence the TSA becomes non-conformant.
Denis
> it's
> possible to observe time-stamp tokens that have inconsistent genTime
> associated with them (eg. the genTime value of a _first_ time-stamp
> token is grater either than the genTime value of a second token, or
> the sum of the accuracies of the two tokens); please refer to my
> previous message for an example.
>
> Thanks,
> alfonso