Subject: Re: New test TSA available

From: [email-masked] (Peter Gutmann)
Date: Mon, 27 Aug 2001 23:41:38 +1200 (NZST)

Jean-Marc Desperrier <[email-masked]> writes:

>A draft is just that, a draft. There isn't, and hasn't to be a formalism for
>interoperability between versions of a draft.

That's exactly the point I was trying to make, that you can't have versions for
something which hasn't even reached 1.0 yet.  Based on the last message from
Todd Glassey, I have the feeling we've been talking about two completely
different things, or at least I don't see how his concept of a version
coincides with the way I thought they worked.

(Actually given that some RFCs seem to be in a perpetual draft state, you may
 need versions for drafts after all :-).

Peter.

---

From: Carlisle Adams <[email-masked]>
Date: Mon, 27 Aug 2001 11:53:12 -0400

Hi Peter,

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	Monday, August 27, 2001 10:54 AM
> To: 	[email-masked]
> Subject: 	Re: New test TSA available
> 
> 
> 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:
 
(...some text deleted...)

> </rant>
 
I'm sure we all appreciated your edifying rant.

Might I suggest that you some day write your own Internet Draft and
successfully guide it to standards-track RFC status, carefully negotiating
your way through scores of requests for additional functionality and
never-ending clarification (over a period of several years) without
compromising your original desire for brevity and simplicity in any way?

Once you have done this, you will no doubt win the heart-felt (albeit
silent) respect of many of your peers.  Unfortunately, you will probably
also have to endure the heart-felt (albeit vocal) criticism of those few who
are still not satisfied.

It's a thankless task, but one I would be happy to see you undertake.

Carlisle.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 28 Aug 2001 14:23:21 +1200 (NZST)

Jean-Marc Desperrier <[email-masked]> writes:
>Peter Gutmann wrote:
>>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 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.

Not really:

 Steal the TSA key
 Use it to submit a benign revocation request to the CA
   (CA revokes cert with a reason like cessation-of-operation).
 Generate as many bogus timestamps as you like
   (The real key owner can't stop you, since the cert/key is
    already revoked).

>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.

A human probably would, but there's no guarantee a CA will (in a
straightforward implementation, a CA will reject any request to revoke a cert
which is already revoked since it's a duplicate).  Basing the correct
functioning of a TSA on what a CA might or might not do (depending on how it's
implemented) is kind of risky.

Peter.

---

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

>I'm sure we all appreciated your edifying rant.

Thanks, it was good for me too :-).

>your way through scores of requests for additional functionality and never-
>ending clarification (over a period of several years) without compromising
>your original desire for brevity and simplicity in any way?

I've already done that, thanks for asking.  There was one change I had to make
in one of them which as far as I can see was purely for cargo cult purposes
which I wasn't terribly happy with (it violated the "Never include a statement
if its negation is obviously false" rule), but mostly they turned out the way I
wanted them (that is, I didn't feel the need to credit them to Alan Smithee
after they were complete :-).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 30 Aug 2001 01:33:01 +1200 (NZST)

tho <[email-masked]> writes:

>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
>
>[...]
>
>is there any particular reason for this double wrapping ?

Yes, PKCS #7 and AuthentiCode.  What happened was that RFC 2630 slightly
changed the definition for eContent, in PKCS #7 this was:

        content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL

but now it's:

        eContent [0] EXPLICIT OCTET STRING OPTIONAL

however there are some implementations which still use the PKCS #7
interpretation (specifically, AuthentiCode, which AFAIK is the only widely-
deployed implementation which signs something other than data (= OCTET STRING)
content).  This uses the ANY DEFINED BY interpretation where ANY is a SEQUENCE
{ ... }, so you get:

        content [0] EXPLICIT SEQUENCE [...]

rather than an OCTET STRING.  My code has a horrible kludge in there to check
the contentType and vary the encoding depending on whether it's an
spcIndirectDataContext or not, so it will produce this encoding as well under
the right circumstances (and in fact in the TSTInfo you saw it had this turned
on for any eContent type, which was wrong, I'll rebuild the test program with
the option disabled in a minute.  With any luck I'll have broken the
AuthentiCode handling now :-).

(I've suggested to the RFC 2630 author that it might be worth including a
cautionary note about this in the RFC update).

Peter.