Subject: Timestamp: CMS vs standalone

From: "Manger, James" <[email-masked]>
Date: Wed, 9 Jun 1999 15:26:17 +1000

The CMS SignedData structure is used for timestamp tokens.  This is a great
structure for signing arbitrary content along with auxiliary information
(authenticated attributes) and packaging all this together with extra info
(unauthenticated attributes) and certificates & CRLs to assist verification.

The timestamp draft says CMS SignedData is used but does not really exploit
its features.  Instead the TSTInfo syntax is basically designed to be
standalone (with its signature).  Others have already suggested using an
authenticated attribute for the TSA name (instead of the tsa field), but
this should apply to other fields as well.  Authenticated attributes seem
the logical place to put policies, nonce, TDA tokens and tsaFreeData.  There
is already a well understood & highly appropriate attribute for the time:
signingTime (PKCS #9).  This basically leaves the content as simply the
messageImprint.  There is even an authenticated attribute specifically for
the imprint: messageDigest!  (I have ignored the serialNumber as a TSA can
easily use extra decimal digits in the GeneralizedTime value to ensure
uniqueness, even beyond the TSA's clock resolution if necessary.)

I am unsure, however, that CMS is the best syntax for a specific security
token like a timestamp.  If you were redefining the Certificate or CRL
syntax today would you use CMS for each?  The following may be simpler:

	Timestamp ::= SIGNED { TSTInfo }
or equivalently
	Timestamp ::= SEQUENCE {
			toBeSigned	TSTInfo,
			algorithm	AlgorithmIdentifier,
			signature	BIT STRING }

The protocol for returning such a timestamp should also allow Certificates
and CRLs to be included (to help the requestor in verifying the timestamp).
HTTP & e-mail protocols are probably easy - return two MIME objects; the
timestamp and a SignedData value with no signers (just certs & CRLs).  The
socket protocol isn't hard but may require explicit fields to hold the certs
& CRLs (outside the timestamp), in a similar fashion to SignedData.

[A Timestamp value can always be repackaged as a CMS value without
re-signing.]