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

[tgindin@xxxxxxxxxx]

     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 <kent@bbn.com> on 09/11/2000 07:12:17 PM

To:   "todd glassey" <todd.glassey@worldnet.att.net>
cc:   <ietf-pkix@imc.org>, "J Adrian Pickering" <jap@ecs.soton.ac.uk>
Subject:  Re: TS TOKEN TYPES - Re: CMC issues, TSP hashes -



Todd,

>Hi all -
>
>----- Original Message -----
>From: "J Adrian Pickering" <jap@ecs.soton.ac.uk>
>To: <ietf-pkix@imc.org>
>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 <jap@ecs.soton.ac.uk>
>  > 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. Hashs, techniques, and maybe even the IOTP Transaction
>types or something like that as well.

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