RFC 3161
Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
RFC 3161 🎀 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) ✨
okay bestie, let's start with the ID card 🪪💖 This is RFC 3161, the Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). It's a Standards Track doc from August 2001, written by C. Adams (Entrust), P. Cain (BBN), D. Pinkas (Integris), and R. Zuccherato (Entrust). The title block doesn't list anything it obsoletes or updates, so it's standing on its own 🦋
Status of this Memo 📜
ok so this part says the document specifies an Internet standards track protocol for the Internet community and asks for discussion and suggestions for improvements 💅 If you want to know where this protocol sits in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍 Distribution of this memo is unlimited, so share it with everyone 🌸
Copyright Notice ©️
Copyright (C) The Internet Society (2001). All Rights Reserved. The legal bit, but make it cute 🎀
Abstract 🫶
this doc is all about the format of a request that gets sent to a Time Stamping Authority (TSA), and the response that comes back 📨 It also sets up a few security-relevant requirements for how a TSA operates when it processes requests to generate responses 🔐 very important stuff, no cap ✨
1. Introduction 🧚
okay so picture this: a time-stamping service lets you prove that a datum existed before a particular time ⏰ A TSA can run as a Trusted Third Party (TTP) service, but other setups may be appropriate too 💜 For example, an organization might need a TSA just for its own internal time-stamping 🏢
Non-repudiation services [ISONR] need to be able to establish that data existed before specified times 🔏 This protocol can be used as a building block to support those services 🧱 There's an example in an annex showing how to prove that a digital signature was generated during the validity period of a public key certificate 📎
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "SHALL", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. This is the rulebook for the capital words, so read it carefully 📚🩷
In order to associate a datum with a particular point in time, a Time Stamp Authority (TSA) may need to be used 🕰️ This Trusted Third Party gives a "proof-of-existence" for that particular datum at an instant in time 🦄
The TSA's whole job is to time-stamp a datum so there's evidence that it existed before a particular time 🎯 This can then be used, for example, to verify that a digital signature was applied to a message before the corresponding certificate was revoked. That means a revoked public key certificate can still be used to verify signatures made before the revocation time, and that's a huge public key infrastructure operation 🙌 A TSA can also show the time of submission when a deadline is critical, or the time of a transaction for entries in a log 📝 Listing every possible use of a TSA is beyond the scope of this document, so we're not doing that 🙈
This standard doesn't set overall security requirements for TSA operation, the same way other PKIX standards don't set those requirements for CA operation 🔒 Instead, it's expected that a TSA will tell prospective clients which policies it uses to make sure time-stamps are generated accurately 📋 Clients should only use a TSA's services if they're satisfied that those policies meet their needs ✅
2. The TSA 🕊️
The TSA is a TTP that creates time-stamp tokens to show that a datum existed at a particular point in time ⭐
For the rest of this document, a "valid request" shall mean one that can be decoded correctly, is of the form specified in Section 2.4, and comes from a supported TSA subscriber 💌
2.1. Requirements of the TSA 📋✨
okay this is the checklist of stuff the TSA is REQUIRED to do 💅 Every one of these matters:
The TSA is REQUIRED:
- to use a trustworthy source of time. ⏱️
- to include a trustworthy time value for each time-stamp token. 🕰️
- to include a unique integer for each newly generated time-stamp token. 🔢
- to produce a time-stamp token upon receiving a valid request from the requester, when it is possible. 📨
- to include within each time-stamp token an identifier to uniquely indicate the security policy under which the token was created. 🪪
- to only time-stamp a hash representation of the datum, i.e., a data imprint associated with a one-way collision resistant hash-function uniquely identified by an OID. 🔐
- to examine the OID of the one-way collision resistant hash-function and to verify that the hash value length is consistent with the hash algorithm. 🔍
- not to examine the imprint being time-stamped in any way (other than to check its length, as specified in the previous bullet). 🙈
- not to include any identification of the requesting entity in the time-stamp tokens. 🫥
- to sign each time-stamp token using a key generated exclusively for this purpose and have this property of the key indicated on the corresponding certificate. 🔑
- to include additional information in the time-stamp token, if asked by the requester using the extensions field, only for the extensions that are supported by the TSA. If this is not possible, the TSA SHALL respond with an error message. 💥 that last bit is a big deal, so don't skip it
2.2. TSA Transactions 💬
so the flow goes like this 🫧 As the first message, the requesting entity asks for a time-stamp token by sending a request (which is or includes a TimeStampReq, as defined below) to the Time Stamping Authority. As the second message, the Time Stamping Authority responds by sending a response (which is or includes a TimeStampResp, as defined below) to the requesting entity 📬
When the requesting entity gets the response (which is or includes a TimeStampResp that normally contains a TimeStampToken (TST), as defined below), it SHALL verify the status error returned in the response 🚦 If there's no error, it SHALL verify the various fields in the TimeStampToken and the validity of the digital signature of the TimeStampToken 🔎 Most importantly, it SHALL verify that what was time-stamped matches what was requested to be time-stamped 🎯 The requester SHALL verify that the TimeStampToken contains the correct certificate identifier of the TSA, the correct data imprint, and the correct hash algorithm OID 🧾 It SHALL then verify the timeliness of the response. It can do that by checking the time in the response against a local trusted time reference, if one is available, or by checking the value of the nonce (a large random number with a high probability that the client generated it only once) included in the response against the value in the request ⏳ For more on replay attack detection, see the security considerations section (item 6) 🛡️ If any of the verifications above fail, the TimeStampToken SHALL be rejected 🚫
Then, since the TSA's certificate may have been revoked, the status of the certificate SHOULD be checked (for example, by checking the appropriate CRL) to verify that the certificate is still valid 🧐
Then, the client application SHOULD check the policy field to see whether the policy the token was issued under is acceptable for the application 📑 ✅
2.3. Identification of the TSA 🪞
the TSA MUST sign each time-stamp message with a key reserved specifically for that purpose 🔐 A TSA MAY have distinct private keys, for example to accommodate different policies, different algorithms, different private key sizes, or to increase performance ⚡ The corresponding certificate MUST contain only one instance of the extended key usage field extension as defined in [RFC2459] Section 4.2.1.13, with KeyPurposeID having the value:
id-kp-timeStamping. This extension MUST be critical. 💯
The following object identifier identifies the KeyPurposeID with the value id-kp-timeStamping 🆔
id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
kp (3) timestamping (8)}2.4. Request and Response Formats 📦
2.4.1. Request Format 💌
A time-stamping request is as follows:
TimeStampReq ::= SEQUENCE {
version INTEGER { v1(1) },
messageImprint MessageImprint,
--a hash algorithm OID and the hash value of the data to be
--time-stamped
reqPolicy TSAPolicyId OPTIONAL,
nonce INTEGER OPTIONAL,
certReq BOOLEAN DEFAULT FALSE,
extensions [0] IMPLICIT Extensions OPTIONAL }okay so the version field (currently v1) just tells you which version of the Time-Stamp request you're looking at 🎀 simple, but it's the foundation of the whole vibe 🧚
bestie, the messageImprint field SHOULD contain the hash of the datum you want time-stamped 🔥 the hash shows up as an OCTET STRING, and its length MUST match the length of the hash value for that algorithm. so like, 20 bytes for SHA-1 or 16 bytes for MD5 💅
MessageImprint ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashedMessage OCTET STRING }the hashAlgorithm field SHOULD be a known hash algorithm (one-way and collision resistant) 🔐 which means it SHOULD be one-way and collision resistant, and yes, that's literally said twice, it's giving emphasis 😭 the Time Stamp Authority SHOULD check whether or not the given hash algorithm is known to be "sufficient" 🧐 that check depends on the current state of cryptanalysis and the current state of the art in computational resources, for example. if the TSA doesn't recognize the hash algorithm, or knows that it's weak (a call each individual TSA gets to make for itself 🫶), then the TSA SHOULD refuse to provide the time-stamp token by returning a pkiStatusInfo of 'bad_alg' 💀 rip to that one
the reqPolicy field, if you include it, tells the TSA which policy the TimeStampToken SHOULD be provided under 📜 TSAPolicyId is defined like this:
TSAPolicyId ::= OBJECT IDENTIFIERthe nonce, if included, lets the client check how fresh the response is when it doesn't have a local clock ⏰ it's a large random number with a high probability that the client only generates it once (think a 64 bit integer, for example) 🎲 in that case the same nonce value MUST be included in the response, otherwise the response shall be rejected 🚫 no nonce match, no vibes
if the certReq field is present and set to true, then the TSA's public key certificate, the one referenced by the ESSCertID identifier inside a SigningCertificate attribute in the response, MUST be provided by the TSA in the certificates field from the SignedData structure in that response 🔑 that field may also contain other certificates too, so it's not a strict guest list 🎀
if the certReq field is missing, or it's present and set to false, then the certificates field from the SignedData structure MUST not be present in the response 🙈 no certificates, no drama
the extensions field is a generic way to add more info to the request in the future ✨ extensions is defined in [RFC 2459]. if an extension is used by a requester but the time-stamping server doesn't recognize it, whether it's marked critical or not critical, the server SHALL not issue a token and SHALL return a failure (unacceptedExtension) 🙅♀️ that's a hard no, babe
one more tea ☕ the time-stamp request does not identify the requester, because the TSA doesn't validate that info (See Section 2.1) 👀 if a TSA actually needs to know who's asking, you'd need alternate identification or authentication, like CMS encapsulation [CMS] or TLS authentication [RFC2246] 🦋
2.4.2. Response Format ✨
okay now the response 💖 a time-stamping response looks like this:
TimeStampResp ::= SEQUENCE {
status PKIStatusInfo,
timeStampToken TimeStampToken OPTIONAL }the status is based on the definition of status in section 3.2.3 of [RFC2510], and it's laid out like this 🌸
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL }when status is zero or one, a TimeStampToken MUST be present 🎉 when status has any other value, a TimeStampToken MUST NOT be present 🙅♀️ and one of the following values MUST be contained in status 🍓
PKIStatus ::= INTEGER {
granted (0),
-- when the PKIStatus contains the value zero a TimeStampToken, as
requested, is present.
grantedWithMods (1),
-- when the PKIStatus contains the value one a TimeStampToken,
with modifications, is present.
rejection (2),
waiting (3),
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5)
-- notification that a revocation has occurred }compliant servers SHOULD NOT produce any other values 🙈 and compliant clients MUST generate an error if they see values they don't understand, no cap 🚨
when the TimeStampToken isn't there, the failInfo explains why the time-stamp request got rejected 😭 it can be one of these values:
PKIFailureInfo ::= BIT STRING {
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badRequest (2),
-- transaction not permitted or supported
badDataFormat (5),
-- the data submitted has the wrong format
timeNotAvailable (14),
-- the TSA's time source is not available
unacceptedPolicy (15),
-- the requested TSA policy is not supported by the TSA
unacceptedExtension (16),
-- the requested extension is not supported by the TSA
addInfoNotAvailable (17)
-- the additional information requested could not be understood
-- or is not available
systemFailure (25)
-- the request cannot be handled due to system failure }these are the only values of PKIFailureInfo that SHALL be supported 🎀 same energy as before: servers SHOULD NOT produce any other values, and clients MUST generate an error if they receive values they don't understand 💅
the statusString field of PKIStatusInfo MAY be used to include reason text, like "messageImprint field is not correctly formatted" 🧚 very helpful, very iconic
now the good stuff, the TimeStampToken ⭐ it's defined as a ContentInfo ([CMS]) and SHALL encapsulate a signed data content type 🫶
TimeStampToken ::= ContentInfo
-- contentType is id-signedData ([CMS])
-- content is SignedData ([CMS])the fields of type EncapsulatedContentInfo in the SignedData construct mean this 🔍
eContentType is an object identifier that uniquely specifies the content type. for a time-stamp token, it's defined as:
id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}eContent is the content itself, carried as an octet string 📦 the eContent SHALL be the DER-encoded value of TSTInfo 🔥
last but definitely not least, the token has strict rules 👑 the time-stamp token MUST NOT contain any signatures other than the signature of the TSA 🙅♀️ and the certificate identifier (ESSCertID) of the TSA certificate MUST be included as a signerInfo attribute inside a SigningCertificate attribute 🔑 it's giving main character energy, but also very strict 💜
TSTInfo is the big struct that holds all the juicy timestamp details 🎀
TSTInfo ::= SEQUENCE {
version INTEGER { v1(1) },
policy TSAPolicyId,
messageImprint MessageImprint,
-- MUST have the same value as the similar field in
-- TimeStampReq
serialNumber INTEGER,
-- Time-Stamping users MUST be ready to accommodate integers
-- up to 160 bits.
genTime GeneralizedTime,
accuracy Accuracy OPTIONAL,
ordering BOOLEAN DEFAULT FALSE,
nonce INTEGER OPTIONAL,
-- MUST be present if the similar field was present
-- in TimeStampReq. In that case it MUST have the same value.
tsa [0] GeneralName OPTIONAL,
extensions [1] IMPLICIT Extensions OPTIONAL }The version field (currently v1) tells you which version of the time-stamp token you're looking at 🦋
Conforming time-stamping servers MUST be able to provide version 1 time-stamp tokens 💖
Among the optional fields, only the nonce field MUST be supported. Nonce is the one optional field you absolutely cannot skip 🫶
Conforming time-stamping requesters MUST be able to recognize version 1 time-stamp tokens with all the optional fields present, but are not mandated to understand the semantics of any extension, if present. So requesters gotta recognize v1 tokens even with every optional field showing, but they don't have to understand extension semantics 🌸 iykyk
The policy field MUST indicate the TSA's policy under which the response was produced. If a similar field was present in the TimeStampReq, then it MUST have the same value, otherwise an error (unacceptedPolicy) MUST be returned. This policy MAY include the following types of information (although this list is certainly not exhaustive):
- The conditions under which the time-stamp token may be used.
- The availability of a time-stamp token log, to allow later verification that a time-stamp token is authentic.
The messageImprint MUST have the same value as the similar field in TimeStampReq, provided that the size of the hash value matches the expected size of the hash algorithm identified in hashAlgorithm. 🔥
The serialNumber field is an integer the TSA assigns to each TimeStampToken 🍓 It MUST be unique for each TimeStampToken issued by a given TSA (i.e., the TSA name and serial number identify a unique TimeStampToken). It should be noticed that the property MUST be preserved even after a possible interruption (e.g., crash) of the service. Even if the service crashes, the uniqueness has to survive 💀
genTime is the time at which the TSA created the time-stamp token. It's expressed as UTC time (Coordinated Universal Time) so nobody gets confused by their local time zone ✨ UTC is a time scale based on the second (SI), as defined and recommended by the CCIR, and maintained by the Bureau International des Poids et Mesures (BIPM). A synonym is "Zulu" time, which is used by civil aviation and represented by the letter "Z" (phonetically "Zulu") 🧚
The ASN.1 GeneralizedTime syntax can include fraction-of-second details. Such syntax, without the restrictions from [RFC 2459] Section 4.1.2.5.2, where GeneralizedTime is limited to represent the time with a granularity of one second, may be used here. The fractions are the extra precision bit 🌈
GeneralizedTime values MUST include seconds. However, when there is no need for precision better than the second, then GeneralizedTime with a precision limited to one second SHOULD be used (as in [RFC 2459]). Only go finer when you actually need it, bestie 🙈
The syntax is:
YYYYMMDDhhmmss[.s...]ZExample:
19990609001326.34352ZX.690 | ISO/IEC 8825-1 provides the following restrictions for a DER-encoding.
The encoding MUST terminate with a "Z" (which means "Zulu" time). The decimal point element, if present, MUST be the point option ".". The fractional-seconds elements, if present, MUST omit all trailing 0's; if the elements correspond to 0, they MUST be wholly omitted, and the decimal point element also MUST be omitted. No trailing zeros, no empty decimal point, period 💅
Midnight (GMT) shall be represented in the form "YYYYMMDD000000Z" where "YYYYMMDD" represents the day following the midnight in question. Midnight is a little plot twist 😭
Here are a few examples of valid representations:
"19920521000000Z"
"19920622123421Z"
"19920722132100.3Z"accuracy represents the time deviation around the UTC time contained in GeneralizedTime 🦋
Accuracy ::= SEQUENCE {
seconds INTEGER OPTIONAL,
millis [0] INTEGER (1..999) OPTIONAL,
micros [1] INTEGER (1..999) OPTIONAL }If either seconds, millis or micros is missing, then a value of zero MUST be taken for the missing field. Missing means zero, easy ✨
By adding the accuracy value to the GeneralizedTime, you get an upper limit of the time at which the TSA created the time-stamp token. In the same way, by subtracting the accuracy from the GeneralizedTime, you get a lower limit of that time 🎀
accuracy can be broken down into seconds, milliseconds (between 1-999) and microseconds (1-999), all expressed as integers. Main character energy 👑
When the accuracy optional field is not present, the accuracy may be available through other means, e.g., the TSAPolicyId. Check the policy if the field is missing 🌸
If the ordering field is missing, or if the ordering field is present and set to false, then the genTime field only indicates the time at which the TSA created the time-stamp token. In such a case, ordering time-stamp tokens issued by the same TSA or different TSAs is only possible when the 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. Basically, if the gap isn't bigger than both accuracies added up, you can't reliably order them 💀
If the ordering field is present and set to true, every time-stamp token from the same TSA can always be ordered based on the genTime field, regardless of the genTime accuracy. Ordering = true is the glow-up 🦋✨
The nonce field MUST be present if it was present in the TimeStampReq. In such a case it MUST equal the value provided in the TimeStampReq structure. Nonce gotta match the request, no exceptions 🫶
The purpose of the tsa field is to give a hint in identifying the name of the TSA. If present, it MUST correspond to one of the subject names included in the certificate that is to be used to verify the token. However, the actual identification of the entity that signed the response will always occur through the certificate identifier (ESSCertID Attribute) inside a SigningCertificate attribute, which is part of the signerInfo (See Section 5 of [ESS]). So the tsa field is just a hint, the real ID comes from the certificate 🔥
extensions is a generic way to add additional information in the future. Extensions is defined in [RFC 2459]. Future-proofing with a bow on it 🎀
Particular extension field types may be specified in standards or may be defined and registered by any organization or community. Anyone can cook up new extension types 🌈
3. Transports ✨
There is no mandatory transport mechanism for TSA messages in this document. The mechanisms described below are optional; additional optional mechanisms may be defined in the future. Pick your vibe, nothing is forced on you 💖
3.1. Time-Stamp Protocol Using E-mail
This section specifies a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 2 and Appendix D via Internet mail. It's giving email as a transport 📧
Two MIME objects are specified as follows:
Content-Type: application/timestamp-query
Content-Transfer-Encoding: base64
<<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>>
Content-Type: application/timestamp-reply
Content-Transfer-Encoding: base64
<<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>>These MIME objects can be sent and received using common MIME processing engines, giving you a simple Internet mail transport for Time-Stamp messages 💌
For the application/timestamp-query and application/timestamp-reply MIME types, implementations SHOULD include the optional "name" and "filename" parameters. Including a file name helps preserve type information when time-stamp queries and replies are saved as files 🫶 When these parameters are included, a file name with the appropriate extension SHOULD be selected:
MIME Type File Extension
application/timestamp-query .TSQ
application/timestamp-reply .TSRIn addition, the file name SHOULD be limited to eight characters followed by a three letter extension. The eight character filename base can be any distinct name. Short, sweet, and unique 🍓
3.2. File Based Protocol
A file containing a time-stamp message MUST contain only the DER encoding of one TSA message, i.e., there MUST be no extraneous header or trailer information in the file. One message per file, no extra fluff 🧁 Such files can be used to transport time-stamp messages using, for example, FTP. Old-school but still slay 💾
A Time-Stamp Request SHOULD be contained in a file with file extension .tsq (like Time-Stamp Query). A Time-Stamp Response SHOULD be contained in a file with file extension .tsr (like Time-Stamp Reply). Name it right and everyone's happy 🌷
3.3. Socket Based Protocol 🔌
Okay so this one is a simple TCP-based protocol for moving TSA messages around 💖 It's giving "best for when an entity starts a transaction and then keeps checking back to see if the results are ready" 🎀
The protocol basically assumes there's a listener process on a TSA that accepts TSA messages on a well-defined port, IP port number 318 🦋
Typically, an initiator binds to this port and submits the first TSA message. The responder replies with a TSA message, a reference number to use later when polling for the real TSA message response, or both 🧚
If a bunch of TSA response messages are going to be produced for one request (like if a receipt has to be sent before the actual token is ready), then a new polling reference gets returned too ✨
Once the initiator has picked up the final TSA response message, no new polling reference is supplied. That's the end of the transaction, bestie 🏁
The initiator of a transaction sends a "direct TCP-based TSA message" to the recipient, and the recipient responds with a similar message 💅
A "direct TCP-based TSA message" consists of:
length (32-bits), flag (8-bits), value (defined below)The length field holds the number of octets in the rest of the message, which is the number of octets in "value" plus one. Every 32-bit value in this protocol is in network byte order 🌸
Here's the message table, and it's giving very organized energy 📋
Message name flag value
tsaMsg '00'H DER-encoded TSA message
-- TSA message
pollRep '01'H polling reference (32 bits),
time-to-check-back (32 bits)
-- poll response where no TSA message response ready; use polling
-- reference value (and estimated time value) for later polling
pollReq '02'H polling reference (32 bits)
-- request for a TSA message response to initial message
negPollRep '03'H '00'H
-- no further polling responses (i.e., transaction complete)
partialMsgRep '04'H next polling reference (32 bits),
time-to-check-back (32 bits),
DER-encoded TSA message
-- partial response (receipt) to initial message plus new polling
-- reference (and estimated time value) to use to get next part of
-- response
finalMsgRep '05'H DER-encoded TSA message
-- final (and possibly sole) response to initial message
errorMsgRep '06'H human readable error message
-- produced when an error is detected (e.g., a polling reference
-- is received which doesn't exist or is finished with)Here's the order these messages can show up in 👀
a) The entity sends tsaMsg and gets back one of pollRep, negPollRep, partialMsgRep, or finalMsgRep.
b) The end entity sends a pollReq message and gets back one of negPollRep, partialMsgRep, finalMsgRep, or errorMsgRep.
The time-to-check-back parameter is an unsigned 32-bit integer. It's the number of seconds for the minimum interval after which the client SHOULD check the status again 🕰️
It also gives a rough estimate of when the end entity should send its next pollReq. So basically, it's the timing hint that keeps everyone on track 🫶
3.4. Time-Stamp Protocol via HTTP 🌐
This subsection is all about carrying ASN.1-encoded messages for the protocol exchanges from Section 2 and Appendix D over the HyperText Transfer Protocol. It's the browser-friendly version, and it's so iconic 🍓
Two MIME objects are defined like this:
Content-Type: application/timestamp-query
<<the ASN.1 DER-encoded Time-Stamp Request message>>
Content-Type: application/timestamp-reply
<<the ASN.1 DER-encoded Time-Stamp Response message>>These MIME objects can be sent and received with common HTTP processing engines over WWW links. They give you a simple browser-server transport for Time-Stamp messages, which is literally so easy 💜
When the server gets a valid request, it MUST respond with either a valid response with content type application/timestamp-response or with an HTTP error. No ghosting allowed 👑
4. Security Considerations 🔐💀
Okay, this entire document is about security considerations, so I'm going to be extra serious here, bestie. When you're designing a TSA service, these are the things that affect whether anyone can trust the time-stamp token 🚨
- When a TSA is retired but its private key has NOT been compromised, the authority's certificate SHALL be revoked. If the
reasonCodeextension for the revoked certificate is in the CRL entry extensions, it SHALL be set to unspecified (0), affiliationChanged (3), superseded (4), or cessationOfOperation (5). In that case, at any future time, tokens signed with that key will be considered invalid, but tokens generated before the revocation time stay valid. If thereasonCodeextension isn't in the CRL entry extensions, then every token signed with that key SHALL be considered invalid. That's why it's recommended to use thereasonCodeextension 📜 - When the TSA private key has been compromised, the corresponding certificate SHALL be revoked. The
reasonCodeextension for that revoked certificate may or may not be in the CRL entry extensions. If it's there, it SHALL be set to keyCompromise (1). Any token signed by the TSA with that private key cannot be trusted anymore, so the TSA's private key has to be guarded with proper security and controls to minimize the chance of compromise 😭 If the key does get compromised, an audit trail of all tokens generated by the TSA MAY help tell genuine tokens apart from false backdated ones. Two time-stamp tokens from two different TSAs is another way to deal with this 🕵️ - The TSA signing key MUST be long enough to allow for a sufficiently long lifetime. Even then, the key has a finite lifetime. So any token signed by the TSA SHOULD be time-stamped again (if authentic copies of old CRLs are available) or notarized (if they aren't) at a later date to renew the trust in the TSA's signature. Time-stamp tokens could also be kept with an Evidence Recording Authority to keep that trust going 🔄
- A client application that uses only a nonce and no local clock SHOULD be concerned about how long it's willing to wait for a response. A `man-in-the-middle' attack can introduce delays. So any TimeStampResp that takes longer than an acceptable period of time SHOULD be considered suspect. Each transport method in this document has different delay characteristics, so what counts as acceptable depends on the particular transport method used, plus other environment factors 🐢
- If different entities get time-stamp tokens on the same data object using the same hash algorithm, or a single entity gets multiple time-stamp tokens on the same object, the tokens will include identical message imprints. As a result, an observer with access to those tokens could infer that the time-stamps may refer to the same underlying data 👀
- Inadvertent or deliberate replays of requests with the same hash algorithm and value may happen. Inadvertent replays happen when more than one copy of the same request message gets sent to the TSA because of problems in the intervening network elements. Deliberate replays happen when a middleman is replaying legitimate TS responses. To catch these situations, several techniques may be used. Using a nonce always lets you detect replays, so its use is RECOMMENDED 🎯 Another option is to use both a local clock and a moving time window, where the requester remembers all the hashes sent during that window. When a response comes in, the requester checks both that the response time is within the time window and that the hash value appears only once in that window. If the same hash value shows up more than once within a time window, the requester may either use a nonce, or wait until the window has moved so the hash appears only once again ⏳
5. Intellectual Property Rights ⚖️
The IETF takes no position on the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't say it has tried to find any such rights. Info on the IETF's procedures for rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claimed rights made available for publication, plus any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification, can be obtained from the IETF Secretariat 📚
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to practice this standard. Please send that info to the IETF Executive Director 💌
The following eight (8) United States Patents related to time stamping, listed in chronological order, are known by the authors to exist at this time. This may not be an exhaustive list. Other patents MAY exist or be issued at any time. This list is for informational purposes. To date, the IETF has not been notified of intellectual property rights claimed in regard to any of the specification in this document. If that changes, the current status may be found at the online list of claimed rights (IETF Page of Intellectual Property Rights Notices) 🌈
Implementers of this protocol SHOULD perform their own patent search and determine whether or not any encumbrances exist on their implementation 🔍
Users of this protocol SHOULD perform their own patent search and determine whether or not any encumbrances exist on the use of this standard 🔍
5,001,752 Public/Key Date-Time Notary Facility
Filing date: October 13, 1989 Issued: March 19, 1991 Inventor: Addison M. Fischer
5,022,080 Electronic Notary
Filing date: April 16, 1989 Issued: June 4, 1991 Inventors: Robert T. Durst, Kevin D. Hunter
5,136,643 Public/Key Date-Time Notary Facility
Filing date: December 20, 1990 Issued: August 4, 1992 Inventor: Addison M. Fischer Note: This is a continuation of patent # 5,001,752.)
5,136,646 Digital Document Time-Stamping with Catenate Certificate
Filing date: August 2, 1990 Issued: August 4, 1992 Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. (assignee) Bell Communications Research, Inc.,
5,136,647 Method for Secure Time-Stamping of Digital Documents
Filing date: August 2, 1990 Issued: August 4, 1992 Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. (assignee) Bell Communications Research, Inc.,
5,373,561 Method of Extending the Validity of a Cryptographic Certificate
Filing date: December 21, 1992 Issued: December 13, 1994
Okay bestie, the patent drama is still going, and these are the receipts 💅🧾
Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr., (assignee) Bell Communications Research, Inc.,
# 5,422,953 Personal Date/Time Notary Device Filing date: May 5, 1993 Issued: June 6, 1995 Inventor: Addison M. Fischer
# 5,781,629 Digital Document Authentication System Filing date: February 21, 1997 Issued: July 14, 1998 Inventor: Stuart A. Haber, Wakefield S. Stornetta Jr. (assignee) Surety Technologies, Inc.,
6. References ✨
Here's the reading list, complete with every detail, so nobody can say we skipped the homework 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, January 1999.
[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure, Certificate Management Protocols", RFC 2510, March 1999.
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[DSS] Digital Signature Standard. FIPS Pub 186. National Institute of Standards and Technology. 19 May 1994.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. Non-Repudiation Framework. April 1997.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[SHA1] Secure Hash Standard. FIPS Pub 180-1. National Institute of Standards and Technology. 17 April 1995.
7. Authors' Addresses 🌸
Meet the squad who wrote this whole thing 🫶
Carlisle Adams
Entrust, Inc.
1000 Innovation Drive
Ottawa, Ontario
K2K 3E7
CANADA
EMail: cadams@entrust.comPat Cain
BBN
70 Fawcett Street
Cambridge, MA 02138
U.S.A.
EMail: pcain@bbn.comDenis Pinkas
Integris
68 route de Versailles
B.P. 434
78430 Louveciennes
FRANCE
EMail: Denis.Pinkas@bull.netRobert Zuccherato
Entrust, Inc.
1000 Innovation Drive
Ottawa, Ontario
K2K 3E7
CANADA
EMail: robert.zuccherato@entrust.comAPPENDIX A - Signature Time-stamp attribute using CMS 🦋
One of the major uses of time-stamping is to time-stamp a digital signature, so you can prove that the signature was made before a certain time. Say the matching public key certificate gets revoked later. This lets a verifier figure out whether the signature came before or after the revocation date. Iconic. 👑
A sensible place to store a time-stamp is in a [CMS] structure as an unsigned attribute.
This appendix defines a Signature Time-stamp attribute that may be used to time-stamp a digital signature. ✨
The following object identifier identifies the Signature Time-stamp attribute:
id-aa-timeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }The Signature time-stamp attribute value has ASN.1 type SignatureTimeStampToken:
SignatureTimeStampToken ::= TimeStampTokenThe value of messageImprint field within TimeStampToken shall be a hash of the value of signature field within SignerInfo for the signedData being time-stamped. 🔥
APPENDIX B - Placing a Signature At a Particular Point in Time 💜
Here's an example of how this general time-stamping service can be used. It places a signature at a particular point in time, and from that point the appropriate certificate status information (e.g., CRLs) MUST be checked. This is meant to be used together with evidence made by a digital signature mechanism. 🧚
Signatures can only be verified according to a non-repudiation policy. This policy MAY be implicit or explicit (i.e., indicated in the evidence provided by the signer). The non-repudiation policy can specify, among other things, the time period a signer gets to declare the compromise of a signature key used for generating digital signatures. So a signature may not be guaranteed to be valid until that time period ends. 🙈
To verify a digital signature, the following basic technique may be used:
- A) Time-stamping information needs to be obtained soon after the signature has been produced (e.g., within a few minutes or hours).
- 1) The signature is presented to the Time Stamping Authority (TSA). The TSA then returns a TimeStampToken (TST) for that signature.
- 2) The invoker of the service MUST then verify that the TimeStampToken is correct.
- B) The validity of the digital signature may then be verified in the following way:
- 1) The time-stamp token itself MUST be verified, and it MUST be verified that it applies to the signature of the signer.
- 2) The date/time indicated by the TSA in the TimeStampToken MUST be retrieved.
- 3) The certificate used by the signer MUST be identified and retrieved.
- 4) The date/time indicated by the TSA MUST be within the validity period of the signer's certificate.
- 5) The revocation information about that certificate, at the date/time of the Time-Stamping operation, MUST be retrieved.
- 6) Should the certificate be revoked, then the date/time of revocation shall be later than the date/time indicated by the TSA.
If all these conditions are successful, then the digital signature shall be declared as valid. 🎀
APPENDIX C: ASN.1 Module using 1988 Syntax 🌈
Last but not least, the ASN.1 module itself, copied exactly as written, every comma and comment included 🤓
PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
Extensions, AlgorithmIdentifier
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)}
GeneralName FROM PKIX1Implicit88 {iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}
ContentInfo FROM CryptographicMessageSyntax {iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1)}
PKIFreeText FROM PKIXCMP {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cmp(9)} ;
-- Locally defined OIDs --
-- eContentType for a time-stamp token
id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
-- 2.4.1
TimeStampReq ::= SEQUENCE {
version INTEGER { v1(1) },
messageImprint MessageImprint,
--a hash algorithm OID and the hash value of the data to be
--time-stamped
reqPolicy TSAPolicyId OPTIONAL,
nonce INTEGER OPTIONAL,
certReq BOOLEAN DEFAULT FALSE,
extensions [0] IMPLICIT Extensions OPTIONAL }
MessageImprint ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashedMessage OCTET STRING }
TSAPolicyId ::= OBJECT IDENTIFIER
-- 2.4.2
TimeStampResp ::= SEQUENCE {
status PKIStatusInfo,
timeStampToken TimeStampToken OPTIONAL }
-- The status is based on the definition of status
-- in section 3.2.3 of [RFC2510]
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL }
PKIStatus ::= INTEGER {
granted (0),
-- when the PKIStatus contains the value zero a TimeStampToken, as
requested, is present.
grantedWithMods (1),
-- when the PKIStatus contains the value one a TimeStampToken,
with modifications, is present.
rejection (2),
waiting (3),
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5)
-- notification that a revocation has occurred }
-- When the TimeStampToken is not present
-- failInfo indicates the reason why the
-- time-stamp request was rejected and
-- may be one of the following values.
PKIFailureInfo ::= BIT STRING {
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badRequest (2),
-- transaction not permitted or supported
badDataFormat (5),
-- the data submitted has the wrong format
timeNotAvailable (14),
-- the TSA's time source is not available
unacceptedPolicy (15),
-- the requested TSA policy is not supported by the TSA.
unacceptedExtension (16),
-- the requested extension is not supported by the TSA.
addInfoNotAvailable (17)
-- the additional information requested could not be understood
-- or is not available
systemFailure (25)
-- the request cannot be handled due to system failure }
TimeStampToken ::= ContentInfo
-- contentType is id-signedData as defined in [CMS]
-- content is SignedData as defined in([CMS])
-- eContentType within SignedData is id-ct-TSTInfo
-- eContent within SignedData is TSTInfo
TSTInfo ::= SEQUENCE {
version INTEGER { v1(1) },
policy TSAPolicyId,
messageImprint MessageImprint,
-- MUST have the same value as the similar field in
-- TimeStampReq
serialNumber INTEGER,
-- Time-Stamping users MUST be ready to accommodate integers
-- up to 160 bits.
genTime GeneralizedTime,
accuracy Accuracy OPTIONAL,
ordering BOOLEAN DEFAULT FALSE,
nonce INTEGER OPTIONAL,
-- MUST be present if the similar field was present
-- in TimeStampReq. In that case it MUST have the same value.
tsa [0] GeneralName OPTIONAL,
extensions [1] IMPLICIT Extensions OPTIONAL }
Accuracy ::= SEQUENCE {
seconds INTEGER OPTIONAL,
millis [0] INTEGER (1..999) OPTIONAL,
micros [1] INTEGER (1..999) OPTIONAL }
ENDAPPENDIX D: Access descriptors for Time-Stamping. 🦋
okay so this annex is a little bonus section 🎀 It describes an extension that's based on the SIA extension, which is going to be defined in the "son-of-RFC2459" document. ngl that doc wasn't out yet when this one got published, so its description lives in this informative annex for now ✨ Once son-of-RFC2459 is finally real, these contents will move over there and this annex won't be needed anymore. A future version will probably skip the annex entirely and just point to son-of-RFC2459 directly 💅
A TSA's certificate MAY contain a Subject Information Access (SIA) extension (son of RFC2459) so that it can share the way to contact the TSA 🧚 The accessMethod field in this extension MUST contain the OID id-ad-timestamping. Literally the one thing it has to hold, periodt 💖
The following object identifier identifies the access descriptors for time-Stamping. It's giving "this is the ID card for timestamp access" 🪪
id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
ad (48) timestamping (3)}The value of the accessLocation field tells you the transport used to reach the TSA (HTTP, for example) and it can also carry other transport-dependent info, like a URL 🌸 So the location is where you go and the transport is how you get there, iykyk 🍓
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. 🔒
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶
📦 where this page comes from
- ietf: rfc3161 2001-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms