[TSA] TimeStampToken(TST)

TimeStampToken(TST)

TSR(TimeStampResp)에서 제일 중요한 것은 TimeStampToken 이다.

이 값은 "시간 문자열"이 아닌 TSA가 서명해서 주는 토큰이다.

 

TimeStampToken은 CMS 구조

RFC3161에서 TimeStampToken은 CMS(SignedData) 컨테이너 구조를 만든다고 설명한다.

즉, 토큰 안에는 보통 다음과 같은 것들을 포함한다.

 

 - 서명(Signature)

 - 서명자(SignerInfo)

 - (옵션) 인증서(Cerificates)

 - 본문 데이터(TSTInfo)

 

TSTInfo

TSTInfo는 TimeStampToken의 본문이다.

RFC3161 기준으로 TSTInfo가 DER 인코딩되어 SignedData의 eContent로 들어간다.

 

또한 토큰에는 TSA 서명 외에 다른 서명이 들어가면 안된다고 명시한다.

 

TSTInfo 주요필드

1. policy

 - 어떤 정책(OID)로 발급했는지

 - 요청에 reqPolicy가 있었다면, 응답 policy도 같아야 한다.(다를 시 unacceptedPolicy)

 

2. messageImprint (중요)

 - hashAlgorithm OID + hashedMessage(해시 값)

 - 요청에서 보낸 messageImprint와 동일해야 한다.

 

3. SerialNumber

 - TSA가 각 토큰에 부여하는 고유 번호

 - 같은 TSA 기준으로 유일

 

4. genTime

 - TSA가 토큰을 생성한 시간

 - UTC 기반으로 표현

 

5. accuracy (optional)

 - genTime의 정확도(오차 범위)

 - 시간 범위(상한/하한) 계산 가능

 

6. ordering (default false)

 - ordering이 true면, 같은 TSA에서 나온 토큰들을 genTime 기준으로 정렬 가능

 

7. nonce (optional, but 중요)

 - 요청에 nonce가 있었으면 응답에도 반드시 존재해야 하고 같아야 한다.

 

8. tsa / extensions (optional)

 - TSA 식별 정보(GeneralName)나 확장 필드가 들어올 수 있다.

 

certReq를 true로 주면 뭐가 달라지나?

요청에서 certReq를 true로 주면, 응답 SignedData의 certficates 영역에 TSA 인증서가 포함되어야 한다.

(포함됐다. != 신뢰된다. 신뢰 체인은 별도 정책/검증 필요)

 

정리

TimeStampToken(TST)은 "시간 값"이 아니라 서명된 토큰이다.

 - TST는 CMS(SignedData) 구조

 - 본문은 TSTInfo

 - 검증에서 제일 중요한 건 messageImprint / nonce 일치 여부

 

참고

 - RFC 3161 (TSTInfo 구조/필드/nonce 규칙 등)

 - RFC 5652 (CMS 개요)

 - RFC 5816 (RFC3161 업데이트: ESSCertIDv2, SHA-1 외 해시 허용)