Subject: gentlemen... can we set aside a specific flag in the TST to represent an official TST?

From: "todd glassey" <[email-masked]>
Date: Sat, 14 Jun 2003 13:27:33 -0700

I want to specify a flag as an attribute that specifies that this TST was
created under the local DSA of the jurisdiction it was done in. For instance
I want an official eSign flag in the TST.

Anyone have a problem with this?, other than it is me suggesting it?

Todd

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 15 Jun 2003 13:26:44 -0700

At 1:27 PM -0700 6/14/03, todd glassey wrote:
>Anyone have a problem with this?,

Yes: it's not specific enough. Please show the exact changes to the 
ASN.1 you propose.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "todd glassey" <[email-masked]>
Date: Sun, 15 Jun 2003 18:09:42 -0700

Paul, thanks for answering. Considering my "persona non grata" status I
figured I would ask the general question first.

The problem is this - How when you use an RFC3161 token to mark
(memorialize) an event do you ascribe jurisdiction or the specific piece of
"commercial policy" or legislative process you want to invoke with it?

The general solution I think it to add an OID of some kind to represent each
Digital Signature Act such that you can reference inside of the TST policy
models. The intent is to make the token more usable by incorporating
features into it that allow Business to more readily use it. The issue of
Jurisdictional notice is an issue.  But some flag also needs to be added to
the request too then

Also there is a concept that there are instances where I would want to
invoke some form of legal coverage on this TST request and not that  one, so
how do I differentiate them? The answer I think is that the TST's need to
allow for one to switch on a request to make a TST under eSign for instance
and others under no legislative cover.

So what I was looking initially for was a single bit we could all agree on
that would be interpreted to have an official status to the TST.  But that
likely wont work under further review. So how about an OID in the request
packet and response packet to indicate that this TOKEN was requested and
signed with a Local Legal Standard brought into play:

   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,
   officialReq           BOOLEAN                  DEFAULT FALSE,
      -- Setting OfficialReq to TRUE causes the local digital signature act
to be invoked
      -- marking this event as a legally enforceable one (whatever that
means).
   extensions            [0] IMPLICIT Extensions  OPTIONAL  }

the other possibility is this:

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,
   officialReq          requestTerms                  OPTIONAL,
      -- requestTerms are a structure defining the three types or
      -- jurisdictional requirements for this TSA.
   extensions            [0] IMPLICIT Extensions  OPTIONAL  }

requestTerms ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   requestJurisdiction     jurisdictionOIDs,
     -- Standard ISO 3166-1 Country and City Codes,
     -- and/or possibly ISO/IEC 7501-1 codes,
     -- or OIDS registered to represent the specific
     -- law's under which this token was built
}

The intent is to include a list of the requested "jurisdictions" or specific
digital signature acts under which this TST was fabricated. This is a
valuable extension to making the TST's more useful.

So here then is a possible response TST:

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.
   officialStatus             StatusResponse           OPTIONAL,
     --a jurisdiction OID as per ISO location country codes of the TSA,
     -- these can be State and Country Codes, Country Codes, or OID
     -- Structures built to represent the actual specific piece of
legislation
     -- that the parties agree to (ISO 3166-1 et al).
   tsa                          [0] GeneralName          OPTIONAL,
   extensions                   [1] IMPLICIT Extensions   OPTIONAL  }

There are probably any number of other ways to do this, and I am open to all
of them so if anyone has any other ideas, lets hear them, but the goal is to
find someway of indicating inside the token "under what terms it was
created" and I am not referring to just the mechanical policy under which
its creation was negotiated.

The vision behind this is that a global TSA could very probably operate any
number of International Timing Services inside the same TSA, and as such
could be creating TST's for clients under any number of legal "agreements"
or criteria. The question is, inside the TSA or other services how you tell
one token's legal ramifications from another. My feeling is that these will
be key features in any commercial TSA moving forward and if we are to
resolve the issues with 3161's then these are things that need to happen to
it IMHO.

Todd Glassey

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, June 15, 2003 1:26 PM
Subject: Re: gentlemen... can we set aside a specific flag in the TST to
represent an official TST?

---

From: "todd glassey" <[email-masked]>
Date: Sun, 15 Jun 2003 19:19:48 -0700

Paul - for the US we also for establishing the selected jurisdiction would
need  to probably include some way of noting the FIPS 5-2 State Name's as
well as the US ISO Country Codes. Germany, the former Soviet Republic,
China, Japan and others will want the same type of granularity so they also
can specify a specific jurisdictional location. We could easily bundle the
legal declaration type into this as well.

Location::    SEQUENCE {
    countryName    ISO-3166-1,
    stateName        stateNameTypes    OPTIONAL,
    -- where stateName can be a FIPS 5-2 or
    -- other 2 ASCII character state name
    legalStatus        lawOID    OPTIONAL,
   -- where lawOID is a registered OID or PENOID
   -- representing the legal constraints under which
   -- this token is issued.
}

Todd

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Jun 2003 20:44:32 -0400

Todd,

None of the additions suggested by you are critical to the basic time 
stamping function defined by the RFC. The function of the protocol is 
to deliver a TST in response to a request by a client, to establish 
the existence of the data represented by the contained hash, at the 
point in time that the TST is issued.

The interpretation of the TST in a legal context is outside the scope 
of this WG, and will likely vary in different "jurisdictions" around 
the world. Thus if any of these additional data items are relevant, 
they may be relevant only in selected contexts and thus are 
inappropriate as data items in the base standard.  As Paul noted, 
these might be considered as extensions to the base protocol, but it 
would be inappropriate to burden the base protocol with such data.

Steve

---

From: "todd glassey" <[email-masked]>
Date: Tue, 17 Jun 2003 19:27:41 -0700

I disagree Steve, and I believe your specific zeal in keeping this as a
purely technical process instead of one that businesses and other entities
can use is more than obnoxious its negligent , but anything less from you to
one of my suggestions would go against virtually all of the communications
between us for the last seven years so Steve, your retort was expected.

----- Original Message ----- 
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>; <[email-masked]>;
"Paul Hoffman / IMC" <[email-masked]>
Sent: Tuesday, June 17, 2003 5:44 PM
Subject: Re: gentlemen... can we set aside a specific flag in the TST to
represent an official TST?

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 18 Jun 2003 10:22:45 -0700

>Anyone have a problem with this?, other than it is me suggesting it?

I avoided that question in my response because it sounded like that 
you recognized your previous problems with your behavior and might 
not repeat them. Your reply above indicates that, no, you are going 
to repeat them.

So, let me add a comment to my first reply: yes, I now have a problem 
with the person suggesting it being you. I would strongly prefer 
suggestions to come from people who act maturely on the mailing list 
and, when confronted with a problem that might stymie them, chooses 
to follow the established rules of the forum in which they are 
working. In this case, that would mean you not writing messages such 
as the one above, and instead writing an Internet Draft and seeing if 
there is interest in the IETF for making it an RFC. You don't need to 
discuss it any more on this mailing list until we have an Internet 
Draft to look at; at that point, we can judge your proposal on its 
technical and procedural merits. Given your track record, I would 
suggest that you get a co-author and let them do most of the posting 
to the mailing list, at least if you are serious about wanting this 
work to become an RFC.

--Paul Hoffman, Director