Subject: TS TOKEN TYPES - Re: CMC issues, TSP hashes -

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 11 Sep 2000 16:27:10 -0600

In this regard, I was interested to hear on the Federal PKI TWG list that NIST 
is considering releasing a SHA-256 and SHA-512 hash algorithm.

No new algorithms will be forthcoming -- the only question is whether to 
bundle them with the conventional signature OID, or to separate them out.

Bundling them makes them somewhat harder to change, but on the other hand, 
allowing complete freedom to choose the signing algorithm independently tends to
raise issue of N-squared combinations that have to be tested.

Some combinations might not even make technical sense -- for example 200-bit
elliptic curve DSA with SHA-512, since the hash function wouldn't fit within the 
signature result.

On balance, and noting the generally poor track record we have in limiting 
combinations of things to stable profiles, I am inclined to continue the practice of
specifying the signature algorithm and the hash algorithm as one joint specification.

Bob

>>> "todd glassey" <[email-masked]> 09/11/00 01:06PM >>>
Hi all -

----- Original Message -----
From: "J Adrian Pickering" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 06, 2000 7:57 AM
Subject: Re: CMC issues, TSP hashes

> At 11:57 06/09/00 +0200, Avi Gozlan wrote:
>
> >- Use of SHA1 is hard coded in section 5.2. This does not leave the
> >standard open for other hash algorithms. Are there any plans to change
> >this?
>
> This is a problem shared with the TSP Draft also.
>
> (see posting -
> Date: Sat, 02 Sep 2000 17:37:43 +0100
> From: J Adrian Pickering <[email-masked]>
> Subject: TSP Draft - hash enforcement &c
> which is rather lost amongst the OCSP debate!)
>
> Please can something be done about this for everyone's benefit? My
> suggestion is to introduce a PKIX globally available OID
> HashAlgorithmIdentifier which is distinct from AlgorithmIdentifier. This
> will enable other hashes to be used where required/wanted. The overloading
> of the AlgorithmIdentifier allows for a parameter which I'm not sure is
any
> use in the hash arena?

Actually Adrian  your right - but I think we need a little more than this.
We need an official PKIX OID Tree and it needs to be available.

For each complex data structure or process that can be uniquely identified
and that would want to be identified, PKIX needs an OID entry in some PKIX
master OID Table. Hash's, techniques, and maybe even the IOTP Transaction
types or something like that as well.

>
> Russ Housley appears to agree: "The selected one-way hash function must be
> uniquely identified by an OID."
>
> I'd still rather have the TSA autonomously stamp an octet string and leave
> the client to decide what it all means.

We are confusing the term "Client" here for the term "USER OF"... and this
is an important concept in understanding what we are really talking about.

The key issue is whether the time stamp is used to control some other
external process, almost analogous to dropping a coin into a vending
machine,
or whether it is standing as evidentiary testimony to some event. As it
happens the Coin does both, but generally the mindset about how the TSP has
been thought about is form using time as a control parameter rather than an
evidentiary one. By the way - We generally as a group seem to assume
automatically between 'using data elements for control' rather than  'for
content'.

In one case they are used to control the infrastructure or policy
like a signal, and on the other they are used to stand audit. The uses of
the same parametric data elements here are very different and have different
needs to support their respective end use models.

> What business is it of the TSA to
> know what it is stamping (semantically or syntactically)?

Depends on what the purpose of the TSA is. If there is a conveyance in a
legal sense of Agency, then the TSA may have legally binding reasons for
being able to identify the type of content it is stamping. Maybe to the
granularity of needing to parse the file first to determine its data type.

.. and this leads us to the fact that a HASH in and of itself as a
timestamping record is very difficult to use from an end user model. What
the TST should be is a framework or harness itself and internally it should
represent a number of events interchangeably. There would need to be
different grades of Tokens with varying levels of overhead for their
management, and the approriate BCP to match.

But realize that in no uncertain terms what we are sitting on is  the
designing of the Global Mint here.

"The real end user goal is a simple bolt-on system that allows end users to,
with the transaction infrastructure they have today,  add non-repudiation
at a commercial level to their process, and  at a scaleable and reasonable
overhead."

Simple to say, not so simple to do as there are so many different
transaction
processing systems in the world today, but the common elements in all of
them is that they have some DB system that they are layered on and an OS
under that of some sort.

With that being the key the DB that is, doesn't the idea of a common binary
data structure that is a timestamp token appeal to you (represented in the
cyber world as ASN.1 if you want) . We can build an TST Binary to XML
presentation system and absorb or bridge the IOTP/XML Receipt efforts at
some level into the PKIX Timestamping systems  and deliver evidentiary grade
standards for representing events in time and space. YOW - look at the
potential
there!!!.

These tokens and their respective API's will be able to specify its level of
trust, the event it marks and the data components that make up that event,
and the rules of processing the token. If a lighter token is necessary
portions of the system can be replaced by OIDS on as "as many as possible"
basis based in the OID tree idea (see above). More risk mitigated
transactions may require self authenticating tokens as well and we should
provide for these at the high end of the API.

Poof - Instant transaction systems. I think that this is what DigiCash and
most all of the other token based transactor companies tried to do but they
were too far ahead of the curve to get real traction - and as scary as it
sounds, PKIX is in the perfect position to make this fly now.

BTW, in and of itself is reason for not advancing the TPS Draft.

>
> Adrian Pickering/
> Electronics and Computer Science
> University of Southampton
> UK
>
>

---

From: [email-masked]
Date: Tue, 12 Sep 2000 14:19:47 -0400

While I do not see any real point to assigning a PKIX-specific OID for
existing crypto algorithms, IMO a relatively severe difficulty in
interpreting some of our formats for newbies is the absence of a real
repository for existing OID's, especially those with cryptographic uses.
The best repository I am aware of is
http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.cfg.  Should PKIX publish
something like this (with more documentation) on its own, or simply link to
Peter's?

          Tom Gindin

Stephen Kent <[email-masked]> on 09/11/2000 07:12:17 PM

To:   "todd glassey" <[email-masked]>
cc:   <[email-masked]>, "J Adrian Pickering" <[email-masked]>
Subject:  Re: TS TOKEN TYPES - Re: CMC issues, TSP hashes -

Todd,

>master OID Table. Hashs, techniques, and maybe even the IOTP Transaction

I've sent mail to Adrian separately re his concerns over the use of
AlgorithmIdentifier, since I don't appreciate the basis for his
concern. But, as for your suggestion above, I am very much puzzled.
We have access to an OID arc from which various PKIX-specific values
are selected, when needed. Algorithms are NOT PKIX-specific and thus
would not be appropriate for this arc. In generating ASN.1 structures
one makes decisions about when an OID is needed, and when locally
interpreted values suffice. I'm not sure we have a lot of examples
where a knowledgeable ASN.1 author would disagree with the choices we
have made.  Could you be more specific in your suggestions? Cite
examples where we have chosen to not use an OID, and then note
comparable situations in other ASN.1 defined protocols where they
have chosen to use an OID.

<snip>

Steve