Subject: RE: Comments on time-stamp-01: Identification of TSA

From: Robert Zuccherato <[email-masked]>
Date: Tue, 25 May 1999 14:35:28 -0400

The tsa field within the token is present to allow end users to obtain the
identity of the supposed TSA without requiring them to obtain the TSAs
certificate.  Considering that the tokens created by a TSA will be used for
non-repudiation in situations very removed (in time and space) from those in
which they were created, it may be useful to be able to refer to the token
with serial number XXXXX from TSA YYYYY, without the only method of
identifying the TSA being their subjectKeyIdentifier (or
issuerAndSerialNumber).

The ESSCertiID Attribute was added, as an option, upon the specific request
of Denis Pinkas.  I don't recall the arguments for it, so I will allow him
to respond directly.

	Robert.

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Monday, May 24, 1999 4:53 PM
> To: 	[email-masked]
> Subject: 	Comments on time-stamp-01: Identification of TSA
> 
> <<File: thayes.vcf>>
> The current time-stamp draft contains several places that define fields
> or recommend use of previously defined fields to identify the TSA
> creating the token.  I believe that the draft provides too many ways to
> do this, which will work against creation of interoperable
> implementations.  In addition, I believe that some of the current
> options are motivated by concerns that are better addressed in other
> ways.
> 
> First, the protocol uses a CMS SignedData object as the basic form of
> the time-stamp token.  This object allows identification of the signer
> in the SignerInfo section.  This data is sufficient to locate the
> correct certificate, build the chain and validate TSA's identity.  This
> should be the primary (and possibly only) method of identifying the TSA
> that generated the token.  However, the current draft goes on to mention
> several other identification fields.
> 
> The draft contains the following text:
> 
>      The purpose of the tsa field is to identify 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.  This field MAY be omitted if the Signing
>      Certificate Attribute has been included as a signed
>      attribute.  (See Section 5 of [ESS].) It MUST be present if
>      the ESSCertID Attribute is not used to identify the TSA.
> 
> 'tsa' is an optional GeneralName field defined within the TSTInfo
> sequence.  Because it is optional, it cannot be relied upon to locate
> the proper certificate needed to verify the token.  It may be useful to
> locate the certificate if a verifier files certificates using values
> other than Issuer/SerialNumber or SubjectKeyIdentifier.  However, the
> TSA would need to know what other types of GeneralName might be useful
> to a client.  The 'tsa' field does have one difference from the
> SignerInfo fields - it is signed with the message.  This has some
> significance for some attacks on the protocol, which I'll discuss later.
> 
> The 'substitution attack' ([ESS]) is prevented for TSA signatures in two
> ways.  First, the key used for signing time-stamp tokens is required to
> be used only for that purpose.  This means that existence of a second
> certificate (with different capabilities) for the same key is already
> prohibited by the draft.  Second, the token also contains a
> PolicyIdentifier that is effect for the signature.  The verifier must
> check that the certificate chain allows this policy to be used.  This
> requirement prevents a second certificate (with different
> PolicyIdentifier values) from being used to check the signature.  In
> fact, the policy identifiers in the SigningCertificate sequence of [ESS]
> duplicate the value already found in the token.
> 
> Finally, the time-stamping draft expresses concern for attacks that may
> occur when the CA does not perform proof-of-possession checks on the TSA
> key.  To counter these, the draft encourages use of the fields mentioned
> above (including the tsa field, and the SigningCertificate attribute)
> which are included within the token signature.  This prevents a
> substitution attack where the substitute certificate is for an entirely
> different subject name.  However, since other drafts will address these
> attacks during the certificate enrollment process (the CMC draft
> contains proof-of-possession protocol), I think the time-stamp protocol
> should not define its own mechanisms for dealing with the problem.
> 
> In summary, there are too many ways to identify the TSA certificate.  We
> should use the basic CMS SignerInfo for this data.  Attacks (as listed
> in [ESS]) Concerns about proof-of-possession flaws should be addressed
> elsewhere, specifically in the certificate request process.
>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 27 May 1999 13:47:21 +0200

Robert,

I have been away during (only) 6 days and the number of ER-mails about the TSP
draft is quite important. I will need to answer some other related E-mails but
let us start by this one where you explicitly mention my name.

> of Denis Pinkas.  I don't recall the arguments for it, so I will allow him

Hum! Since you raised the question, to tell the truth I was/am only advocating
the use of ESSCertiID and the current document is the reflect of a (good/bad ?)
compromise.

Robert, you said : "The tsa field within the token is present to allow end users
to obtain the identity of the supposed TSA without requiring them to obtain the
TSAs certificate." A TSP caller will have anyway to verify the signature of the
TSA, so it will always need the TSAs certificate (i.e. the issuerAndSerialNumber
field). The name in the token itself is both insecure and useless. It is
insecure because it does not handle TSA name collission properly, so it can only
be used as an hint. The hint is not very useful anyhow since it does not allow
to point to all the TSA homonyms (if any). It is useless because it does not
allow to point unambigoulsly to the right certificate. So supporting the
identification of the TSA in the signer info is not really an option but a need.
So I agree that there are too many ways to identify the TSA.

Denis

---

From: "Todd S. Glassey - ELN" <[email-masked]>
Date: Thu, 27 May 1999 10:26:21 -0700

----- Original Message -----
From: Denis Pinkas <[email-masked]>
To: Robert Zuccherato <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 27, 1999 4:47 AM
Subject: Re: Comments on time-stamp-01: Identification of TSA

> > of Denis Pinkas.  I don't recall the arguments for it, so I will allow
him

How does this architecture allow me to trace the origin of the time data
itself and what qualifies it in the timestamp as being legitimate. Just
because said so?

---

From: Stephen Kent <[email-masked]>
Date: Thu, 27 May 1999 13:55:18 -0400

Todd,

There is no requirement that the time stamp carry info that purports to
trace the origin of the time source.  That info may be expressed in the
TSA's policy, as a static assertion, unless the WG determines that such a
static assertion is not sufficiently flexible.  For example, a TSA might
say that they use GPS, or use a specific NIST source, or whatever.  So long
as the policy can be associated with the TSA that should suffice.  I assume
that a TSA will tend to be consistent, for fairly long periods, in its
choice of time source, so a facility to record this data in each token seem
like overkill.

Steve

---

From: "Todd S. Glassey - ELN" <[email-masked]>
Date: Thu, 27 May 1999 16:29:34 -0700

Stephen
I respect and appreciate your accomplishments but I think you dead wrong
here and everything I have had to live through for the last two years tells
me I am right.  My issue in saying this publicly is that "Stephen Kent" is a
name that carries a lot of weight when it is attached to an opinion, which
is why I am so baffled as to your resistance to building in these proofing
facilities into the timestamping process.

It seems to me that what we are focusing on here is an elaborate mechanism
to pass relative time through a distributed infrastructure, rather than the
real goal - that being to have a system for representing events in time that
is accurate, believable, and commercially viable.  Mark the phrase
"Commercially Viable", because it is the key to any market success we will
have unless someone puts a law in place to mandate our products.

Personally, I am starting to want to call this timestamping protocol the
Bradley Fighting Vehicle of the PKIX group - ever see Kelsey Grammer in
"Pentagon Wars" - and although I know that is not true, it's sorta how I
feel about all the abuse I have taken for questioning the use and
architecture of this effort's end goals.  The ultimate reason for my
responses here is driven in the simple economic fact that if I have to shell
out money for this technology, it better pay me back somehow.

As to your commentary particular that "it's not there" below, that is to
say, the ability in the protocol to prove the chain of custody against the
time source - I know it's not there and I am trying to figure out why.

What I think we have built here today is a system that requires the user or
operator to jump through external hoops to prove the process and model of
operations at the sites are OK, otherwise the timestamps issued are of
questionable veracity and as such there use and reception are likely to be
limited.

As to the existing draft's specification, my problem is that I have still
not figured out a legally binding model for a large enough segment of the co
mmercial world to use this timestamping technology, that this makes
commercial sense.

DONT GET ME WRONG - I AM NOT TRYING TO TELL YOU THAT THE ZUCCERATTO, et al.
DRAFT IS BROKEN, just that I want to understand the use models driving all
this effort in detail.

----- Original Message -----
From: Stephen Kent <[email-masked]>
To: Todd S. Glassey - ELN <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 27, 1999 10:55 AM
Subject: Re: Comments on time-stamp-01: Identification of TSA

> static assertion is not sufficiently flexible.

I question this

> For example, a TSA might
> say that they use GPS,

Stephen, personally I don't think that this will ever happen in a
commercially functional sense.

#1  no one would who needs a really viable audit done would use and rely on
the timedata from GPS alone, since the US Air Force controls it. Also there
is the real world a pretty major problem in that the GPS sattillites that
are currently available are going to start decommissioning themselves
because their Atomic Clocks are out of cal [becuase of their age] and  as
such, they cannot be adjusted or refurbished in their current orbits.

From my last understanding, the US Congress has reallocated the replacement
GPS Sattellite launch slots on the STS  (the Shuttle) to other "projects"
including the international space station, so at last count GPS is sort of
dying... or its at least being ignored. Also, I further understand that
there is a funny issue ofthe  Air Force trying to unload the operational
costs and responsibility for operating the GPS network since they don't need
it to pilot warheads down a chimney pipe from orbital anymore. Intertial Nav
being what it is these days and precision timepieces themselves...

If I am wrong here, would someone from the Fed, NIST, or the Air Force step
in and set  the record straight for all of us?

#2  I  seem to recall Judah Levine, NIST's master timekeeper, mentioning
several occaisions where the Air Force had actually intentionally diddled
the time to make it inaccurate for 'wartime service reasons', and since GPS
has no authentication for the public users, this commercial relaince just
doesn't make sense.  If you have any doubt of this check with Pat Cain, the
remark was part of Judah's general presentation to the ISC in Seattle last
September, and  we were both there so he can verify  this

#3 Also, as another issue about the physical act of deploying GPS, most
commercial customers would need Roof Access or something similar to support
their GPS site, unless they buy Datum's new RF system for locally
distributing GPS...  [Anyone from Datum want to jump in here? Dave, Bill,
Ron, Greg?].

#4 Not to mention GPS's epoch is coming this August 22nd and none of the
cheap systems will be able to deal with it that I know of.

Datum and the other players had to extensive firmware updates to support the
rollover in their receivers, since when the AF designed GPS they assumed we
would all be dead now or the system no longer in operation. That's why the
10 bit wide week counter is it in GPS. Nice thought, eh?

Don't lose complete faith, all in all, they (Congress) will likely address
this when the multitude of Cadillac Owners gets PO'd that their NorthStar
Autolocator's don't work, or you turn your GPS system on and it say's
"HELP - NO SATTELLITES ACQUIRED".

Now, alternatively - there is GLONAS, but the Russian's are not looked on
too favorably in the technical services arena to date, so it is unlikely
that this system will be implementad as a commercially viable timesource
without a new operator... like maybe the UN (just my own opinions here,
BTW). Likewise, in Germany the have the DFS77 system. My point is that very
few countries outside the US trust GPS and rightly so.

So, unless maybe some member of the Big-4 Audit staff wants to publicly
stand up and say GPS is OK by us and our customers the world over, I'll
rest this issue.

>or use a specific NIST source,

In this country or in any country that contracts with NIST to operate their
"Clock's",  this would be fine - if you could show how the time data got to
you and you could prove the chain of custody against it. Currently the
public NIST servers do this.

>or whatever.

Annnnnngggggggghhhhhh (insert "Buzzer" sound here)- This last one is the
wrong answer from my viewpoint, "whatever" means that we get to 'free-form'
our proofing models - so I have to ask the rhetorical question "whats the
point of standardizing the methodology of building the token structure as we
are with these efforts, if the time data is crap and unrelaible?", becuase
then it all comes down to my word against your and thats worthless to me as
a commercial provider. It seems to me that tghe real issue here in the
relative timestamping systems is that they cannot deal with the issue of
distributing legally relaible time. Its not that hard. Its just that its
something that you have to go talk to a physicist about rather than a
programmer, eh?

> So long
> as the policy can be associated with the TSA that should suffice.

I disagree here too - The value of the timestamping is in the stability of
the event representation structure that is produced as  the evidentiary
output of the proofing services. Not in the TSA's policy that operates it.
The TSA's policy is only an attribute of the engine creating the stamp.

>I assume
> choice of time source,

Steve, I think that this is a bad assumption to make. I think that
timestamping is something that will happen to the bigger picture and that
the commercial world will absorb the overhead of the token structure and
processing info, but that they need absolute, not relative timestamping.

In closing, I feel that this Time Stamping is important for making EC a
global thing like it could be. So pardon my "enthusiasm", but here the real
issue is the International Standarization on the event representation
mechanism, i.e. the token itself. The method of creating it is important,
but is a secondary consideration.This is why the BERT proposal is so
powerful (http://www.gmtsw.com/ietf).

Todd

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 28 May 1999 11:43:40 +0200

Todd,

Altough this E-mail is primarily for Steve, I would like to make a few comments
on it:

1° I think that the tone that is being used in your reply here is not adequate
and should be moderated.

2° We are defining a Time Stamping Protocol that can be used in many dfferent
contexts. We do not claim that it is usable in all the contexts. We have made a
few *simple* extensions that were beyond the original goal, in particular to be
able to answer to the simple question "What time is it ?" when the requester has
no local time available. The primary need is only to prove that a digital
signature was created before a given date. That digital signature may be any
signature; e.g. from a user; from a CA for a user certificate,
cross-certificate, CRL, ARL; from an Attribute Authority for an Attribute
Certificate ... As there are too many examples of use, only a few are mentioned
in the annex.

3° The protocol is sufficient for our current needs. Thus I do not see the need
to extend the terms of reference of our charter to cover more.

Regards,

Denis
(co-author of the current draft)

---

From: "Todd S. Glassey - ELN" <[email-masked]>
Date: Fri, 28 May 1999 08:03:49 -0700

Denis, this is degrading at this point and so I apologize to the group. I am
taking the remainder of my commentary to you and the other Draft Creators
offline, so I don't have to burden the list with the rest of my thoughts on
this matter.

Todd