[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Timestamping Standards.



Todd & Mike,

>Denis, Robert - here we are again, disagreeing on the Time Stamping
>Protocols.
>
>OK, if I agree to drop these issues, can I/we add an appendix or supplement
>to the current draft that contains a BCP model for maintaining the Clock
>Timebase. This of course would be at the OS level, that is below the TS
>Protocol that would be use-model compliant with OATS requirements.
>
>This would satisfy me and would allow the process to continue with this
>status-quo.
>
>Also this addition would address the need for this BCP Model in the 'Road
>Map' as well, and eliminate the need to address this further for any other
>of the protocols being forged in the furnace of PKIX or its related WG's.
>
>Bluntly, this appendix could be a recommendation for timebase management in
>all PKI or IETF Operating Models.

After the last IETF meeting I spoke with one of the security area directors
briefly, to discuss the question of BERT and similar time stamping issues.
There was agreement that tmost aspects of the proposals that you have put
forward are outside the scope of what we need to do in the PKIX
environment, given the long standing model for TSAs and a desire to not
impose constraints on how a TSA chooses to maintain its time base.
Moreover, there was agreement that the STIME WG provides a suitable
Internet standard for time representation, if we wish to refer to formats
consistent in the IETF arena.  Since I stated at the last meeting (and
reported in the minutes) that the WG chairs would consider the question of
whether BERT was within scope, and based on the feedback from a security
AD, I have decided that, going forward, PKIX will not address the
definition of a time token representation ala BERT or analogous proposals.

In the last couple of months, Todd proposed creation of a separate WG for
this sort of task and if the IESG agrees, one can be established.  However,
from now on, PKIX will not devote additional resources to this topic.  It
has not been an accepted work item, and enough time has been devoted to its
consideration for us to decide against adding it.

Steve