摘要
本文件描述TSA(Time Stamp Authority) 接收時戳要求與回應時戳的格式，以及TSA運行時相關的安全要求。
介紹
時戳服務提供證明某一文件或資料在某一時點就已存在的事實，TSA可以由公正第三機構(Trusted Third Party, TTP)來運行，也可以其它方式來實行，例如組織可以自行建立TSA做為內部使用之時戳服務。
TSA就是提供時戳服務的公正機構, 也就是要來提供某一資料在某一時點就已存在的證明。
TSA的角色是要去為一份資料「押時戳」以建立該資料在某一時點就已存在的證據，可驗證雖已失效的憑證其之前所簽署的文件，此為PKI運作之重要特性。在截止時間是非常重要的情況下, TSA用來可表示交付時間，或在交易日誌裡, TSA用來表示每一項記錄的時間。
此份標準並不是要建立TSA運作上所有的安全要，正如其他PKIX標準並不是要建立CA運作的所有要求，而是要讓時戳的使用者了解產生準確時戳的政策，使用者了解並滿足其需求後, 也就能充分使用TSA提供的時戳服務。
TSA
TSA 是一個產生時戳標記(Time Stamp Token)的公正機構, 此標記能指證某一資料在某一時點就已存在。
TSA 的需求
(1) 使用可信任的時間源(Time Source)
(2) 每一個時戳標記應包括一個可信任的時間值(Time Value)
(3) 每一個新產生的時戳標記應包括一個唯一的整數值
(4) 一收到時戳需求就要立即產生一個時戳標記
(5) 每一個時戳標記要包含一個唯一的識別碼(ID)代表此標記產生時的安全政策
(6) 對代表此資料之湊雜值(Hash)即資料印記(Imprint)做一時間戳記(time-stamp)
(7) 檢查Hash function的OID及湊雜值長度是否無誤
(8) 不用檢查Imprint內容 (除了長度外)
(9) 時戳標記不要包括其它代表需求端的識別碼
(10) 使用為時戳目的的憑證的金鑰來簽署(sign)此時戳標記
(11) 時戳標記可以有TSA支援的延伸欄位, 必要時可以在此放額外資訊。
TSA處理 (Transaction)
此機制的第一個訊息為需求端(Requesting Entity)為取得時戳標記而送給TSA的需要訊息(Request), 此可以是或包括TimeStampReq. 第二個訊息為TSA回應給需求端的回應訊息(Response), 此可以是或包括TimeStampResp。
一旦收到回應(是或包括TimeStampResp, 通常包含TimeStampToken[TST])在內)，需求端應該檢查回應訊息狀態是否有錯誤，然後檢查TST內的欄位, 再驗證TST的數位簽章，特別要確認回應與要求的對應。需求端要確認 TST裡包含的TSA的憑證代號、資料印記、Hash function的OID。然後檢查回應的及時性(可比對回應訊息內的時間, 或檢查需求訊息與回應訊息內的nonce值), 其它關於如何偵測重播供擊(Replay Attack)可參看後文安全考量項目。如果以上任何檢查有誤，應拒絕此TST。
因為TSA的憑證可能無效(過時或被取消)，必須檢查憑證的有效性。
需求端還應檢查TST的Policy 欄位是否符何合要求。
TSA 身份識別
TSA 必須用此特定目的的金鑰來簽署所有發出的時戳訊息，TSA 可以有各種不同的私鑰以符不同的要求，例如：不同政策(Policy)、不同演算法、不同私鑰長度等。其對應的憑證必須包含剛好一個延伸的金鑰使用標的的欄位，內含此值：
id-kp-timeStamping
RFC 3161 原文資料: http://www.ietf.org/rfc/rfc3161.txt
