Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a specific flag in the TST to represent an official TST?)

From: Tom Gindin <[email-masked]>
Date: Tue, 17 Jun 2003 14:24:43 -0400

Responses below.  I'm not recommending a private extension, but a 
standard published one.  I don't think this belongs in pr-tsa.

                Tom Gindin

"todd glassey" <[email-masked]>
06/17/2003 01:48 PM

        To:     Tom Gindin/Watson/IBM@IBMUS, "Cain, Patrick" <[email-masked]>
        cc:     <[email-masked]>
        Subject:        Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a 
specific flag in the TST to represent an official TST?)

Tom and Pat (and all TST fans out there in PKIX land) -

I agree that with the contention over the NR bit that any issues that 
impact
the use of the TST in commercial instances are a problem. But my concerns
for this are simple, and that is from a governance or commercial
applications process, I think. Remember that the only possible use of a 
TST
is as a receipt. So then it becomes inherently obvious that it is likely
that a single TSA will be issuing any number of TST's to their customers
under different sets of legal and cultural requirements, and with that as 
a
realization one has to asks how with the current token would this be done?

[TG]    It's not the only possible use, but it is an important one.  Proof 
that a digital object has not been modified is not a receipt.

You are right that we could force each and very user to come up with their
own interpretation and system, since he extensions  but is that a good 
idea?

[TG]    We need a standard extension, profiled in son-of-3161 (if any) or 
a separate informational RFC.  Private extensions are not very 
interoperable.

For instance one could argue that the extensions and their use are 
something
for a BCP, but since these really are what make the token usable in the
first place I think that its uses are too limited without these defined as
at least optional in nature, that we will not succeed in getting 3161
ubiquitously integrated in eBusiness and eGovernment processes.

With that said, I would support the addition of a small section to the RFC
to address this or an additional SonOf RFC3161 being done that uses this.

BTW - I know this group is winding down but as part of this specific 
effort
I would also encourage this group to also look at creating an ORACLE
Compliant API for use of these services in the 11i and subsequent
applications packages.

Todd

----- Original Message ----- 
From: "Tom Gindin" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 17, 2003 6:59 AM
Subject: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a
specific flag in the TST to represent an official TST?)

>
>         Todd:
>
>         Shouldn't this be an extension?  It seems to me that the 
extension
> facility was included in both TimeStampReq and TSTInfo for just this 
sort
> of thing.  If you use an extension, since it's characterized by an OID,
> you don't need a version number.  Thus the ASN.1 of the request form is
> just SEQUENCE OF JurisdictionID, with
> JurisdictionID ::= CHOICE {
>         iso3166         PRINTABLE STRING,
>         statuteID       OBJECT IDENTIFIER
> }
>         The response is another extension with the same syntax.
>         Legal evidence is not the only reason for a TSA, but it's
> certainly a potentially important one.
>
>                         Tom Gindin
>
>
>
>
>
> "todd glassey" <[email-masked]>
> Sent by: [email-masked]
> 06/15/2003 09:09 PM
>
>
>         To:     "Paul Hoffman / IMC" <[email-masked]>
>         cc:     <[email-masked]>
>         Subject:        Re: gentlemen... can we set aside a specific 
flag
in the TST to represent
> an official TST?
>
>
>
>
> 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?
>
>
> >
> > At 1:27 PM -0700 6/14/03, todd glassey wrote:
> > >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?,
> >
> > Yes: it's not specific enough. Please show the exact changes to the
> > ASN.1 you propose.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
>
>
>
>