Subject: Re: New test TSA available

From: [email-masked] (Peter Gutmann)
Date: Tue, 28 Aug 2001 02:54:20 +1200 (NZST)

I've now updated the TSA to conform to the latest draft (except for the TSA
cert, because I'm using a shared generic cert which gets recycled for SSL,
OCSP, CMP, and everything else).  And now a rant about the latest draft...

<rant>

Since I last looked at this, it seems to have picked up an incredible amount of
unnecessary and confusing cruft.  There are two main things which stand out,
the first is that everything seems to be repeated two or three times over,
sometimes in consecutive sentences but usually spread far apart and stated in a
contradictory and confusing manner.  The other thing is that there seems to be
way too much text in there which doesn't serve any purpose except to confuse
the reader.  For example consider the bit which begins:

  The messageImprint field SHOULD contain the hash of the datum to be time
  stamped.  The hash is represented as an OCTET STRING. Its length MUST match
  the length of the hash value for that algorithm (e.g. 20 bytes for SHA-1 or
  16 bytes for MD5).

As opposed to the alternative 50-byte OCTET STRING for SHA-1?  What other
option is there, and why is it even necessary to specify this?  One useful rule
which someone once told me when writing something like this is "Never include a
statement if its negation is obviously false", there's no need for that entire
statement because there's no other length possible for a given hash function.

  The hash algorithm indicated in the hashAlgorithm field SHOULD be a known
  hash algorithm (one-way and collision resistant). That means that it SHOULD
  be one-way and collision resistant.

As opposed to a hashAlgorithm for a known hash algorithm (one-way and collision
resistant) which isn't one-way and collision resistant perhaps?

  The Time Stamp Authority SHOULD check whether or not the given hash algorithm
  is known to be "sufficient" (based on the current state of knowledge in
  cryptanalysis and the current state of the art in computational resources,
  for example). If the TSA does not recognize the hash algorithm or knows that
  the hash algorithm is weak (a decision left to the discretion of each
  individual TSA), then the TSA SHOULD refuse to provide the Time Stamp Token
  by returning a pkiStatusInfo of 'bad_alg'.

This whole text block doesn't say anything useful, and even if it did it's
matter of TSA policy and/or interop profiles/signature legislation/whatever to
decide what does and doesn't constitute an acceptable hash algorithm.  Since
the text doesn't say anything useful (it leaves it open to the TSA to do
whatever they want), why is it even here?

  If the certReq field is missing or if the certReq field is present and set to
  false then the certificates field from the SignedData structure MUST not be
  present in the response.

Given that the field is DEFAULT FALSE, it can never be "present and set to
false".

  The extensions field is a generic way to add additional information to the
  request in the future. Extensions is defined in [RFC 2459]. If an extension,
  whether it is marked critical or not critical, is used by a requester but is
  not recognized by a time stamping server, the server SHALL not issue a token
  and SHALL return a failure (unacceptedExtension).

This text first defines extensions in terms of RFC 2459 and then in the next
sentence specifies handling of extensions which directly contradicts RFC 2459.
Why is it necessary to have this special-case handling for extensions?  Given
that TSAs will (presumably) be using standard implementations of whatever
standards are appropriate (X.509 and CMS), is it really necessary to specify an
extension-handling behaviour which differs from either of the standards which
TSP is built on?

It's made even worse in the second place where extension-handling behaviour
is specified:

  Conforming timestamping requesters MUST be able to recognize version 1
  Timestamp tokens with all the optional fields present, but are not mandated
  to understand the semantics of any extension, if present.

This time it's still behaviour which contradicts RFC 2459, but now it also
contradicts the behaviour mandated earlier in the same draft (admittedly one is
for clients and the other for servers).  Is there any reason for not following
the standard (that is, RFC 2459) on this?

There are other places where non-RFC 2459 behaviour is mandated, for example:

  When the reasonCode extension relative to the revoked certificate from the
  TSA is present in the CRL entry extensions, it SHALL be set either to
  unspecified (0), affiliationChanged (3), superseded (4) or
  cessationOfOperation (5).

when RFC 2459 says:

  CAs are strongly encouraged to include meaningful reason codes in CRL
  entries; however, the reason code CRL entry extension SHOULD be absent
  instead of using the unspecified (0) reasonCode value.

(in fact the whole section which contains this text is a bad idea, I'll go into
this in more detail further on).

Now we get to a tour de force example of the "Never include a statement if its
negation is obviously false" rule:

  Compliant servers SHOULD NOT produce any other values.

Given that there are no other values defined, what other option could there
possibly be? -> Never include a statement if its negation is obviously false.

  Compliant clients MUST generate an error if values it does not understand are
  present.

As opposed to, say, inventing values which look plausible and continuing? ->
Never include a statement if its negation is obviously false

  These are the only values of PKIFailureInfo that SHALL be supported.

Given that there are no other values defined, what other option could there
possibly be? -> Never include a statement if its negation is obviously false.

  Compliant servers SHOULD NOT produce any other values.

Yes, we know, you just told us that -> Never include a statement if its
negation is obviously false.

  Compliant clients MUST generate an error if values it does not understand are
  present.

See above -> Never include a statement if its negation is obviously false.

  The certificate identifier (ESSCertID) of the TSA certificate MUST be
  included as a signerInfo attribute inside a SigningCertificate attribute.

  [...]

  the certificate identifier (ESSCertID Attribute) inside a SigningCertificate
  attribute which is part of the signerInfo (See Section 5 of [ESS]).

This appears to be contradictory, but if you read it carefully it's probably
saying the same thing.  This is another example of how repeating the same thing
several times in different locations does nothing but confuse the reader. There
are other places where similar things occur... I'm sure that I could remove at
least 25% of the total text in the draft without it having any effect except to
improve legibility.

The first item in "Security Considerations" (referred to above) is pretty
risky.  An un-compromised TSA key should be destroyed, but not explicitly
revoked.  If it is revoked then it's necessary to create a benign vs serious
revocation condition (which is what the text does) which can be exploited
because all I need to do after stealing the TSA key is to revoke it in a benign
manner and then generate all the fake timestamps I want.  The real key owner
can't do anything about it because my benign revocation has pre-empted any
attempt at a serious revocation.  A better suggestion would be to use short-
term TSA keys, which sidesteps the whole problem.

</rant>

Peter.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 27 Aug 2001 19:26:41 +0200

Peter Gutmann wrote:

> manner and then generate all the fake timestamps I want.

The TSA is signed by a CA.
If I steal the TSA key, I can forge timestamp, but not the revocation information.
I'd need to steal both keys to do that.

Self-signed TSA certificate is against the letter of the draft, the key should be
used only to sign request.
I know this is pushing it a bit far, but in a discussion about that, the draft's
authors seemed to agree with that interpretation.

> The real key owner
> attempt at a serious revocation.

I'm not sure.

If the TSA's CA does not revoke the TSA, that mean it will sign information that
says it's not revoked.
The key stealer has the choice between signing non-revoked information or benign
revocation information.

If I get two different revocation information for a TSA, information A saying it's
benign revocation, and B saying it's serious revocation, I would consider it
serious revocation.

Guessing what the user will be able to do in case of compromise of the key used for
revocation information is a bit difficult.

---

From: tho <[email-masked]>
Date: Wed, 29 Aug 2001 12:27:46 +0200

hi peter, 

i've tried a tsreq against the updated tsa.cryptoapps.com and i had a problem 
with eContent while decoding the response:

draft (rfc) states that "The eContent SHALL be the DER-encoded value of 
TSTInfo" instead it seems that you wrapped it into a further SEQUENCE so that 
the resulting token appears as

    ...
    {                            (EncapsulatedContentInfo)
      1.2.840.113549.1.9.16.1.4, (id-ct-TSTInfo)
      ANY [length = 94]          (SEQUENCE { DER encoded TSTInfo })
        30:5C:30:5A:02:01:01:06:0A:2B:06:01:04:01:97:55:
        38:24:36:30:1F:30:07:06:05:2B:0E:03:02:1A:04:14:
        31:32:33:34:35:36:37:38:39:30:61:62:63:64:65:66:
        67:68:69:6C:02:11:00:BD:F4:4F:D9:70:D7:27:D3:14:
        96:C2:CB:7F:86:73:96:18:0F:32:30:30:31:30:38:32:
        39:30:32:31:32:35:36:5A:02:04:00:9A:21:12
    },
    ...

rather than

    ...
    {                            (EncapsulatedContentInfo)
      1.2.840.113549.1.9.16.1.4, (id-ct-TSTInfo)
      ANY [length = 94]          (DER encoded TSTInfo)
        30:5A:02:01:01:06:0A:2B:06:01:04:01:97:55:38:24:
        36:30:1F:30:07:06:05:2B:0E:03:02:1A:04:14:31:32:
        33:34:35:36:37:38:39:30:61:62:63:64:65:66:67:68:
        69:6C:02:11:00:BD:F4:4F:D9:70:D7:27:D3:14:96:C2:
        CB:7F:86:73:96:18:0F:32:30:30:31:30:38:32:39:30:
        32:31:32:35:36:5A:02:04:00:9A:21:12
    },
    ... 

is there any particular reason for this double wrapping ?

bye, tho
--