Subject: CMC issues

From: Avi Gozlan <[email-masked]>
Date: Wed, 06 Sep 2000 11:57:42 +0200

Hi,

After reading CMC, I have got questions about the standard. Comments are
welcomed.

- ASN.1 module issues:
1. In the module, pendToken in pendInfo is defined to be an INTEGER,
while queryPending is defined as OCTET STRING in 5.13.

2. The definition of bodyList in 5.1 is “SEQUENCE SIZE (1..MAX) OF
BodyPartID” while in the module it is defined as “SEQUENCE SIZE (1..MAX)
OF INTEGER”

3. The module imports AttributeCertificate and CertificateList. Both are
superfluous.

- 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?

- If the shared secret method is used as proof of identity, it may be
exposed to off line dictionary attack (if supplied by the user). Usually
such an attack becomes harder by enforcing expensive computation for
each trial of a shared secret (computation of the hash 1000 times or
so). The CMC standard does not use this technique. It should at least
state that the shared secret must be randomly chosen (not a user
supplied password).
This attack is usually meaningless, as the shared secret is used only
once, however, if the initial enrollment request fails, the same secret
may be used in following requests (the standard does not require
replacement of it). As mentioned, a requirement of randomly chosen
secret may solve this.

- It seems to me that the single round trip preference mentioned in
section 1 cannot come along with the industry practice of PKCS#10/PKCS#7
(mentioned in the same section). Proof of Identity may be supplied in
the full enrollment message (thus not using the PKCS#10 request) or
pending token must be returned (and having more then single round trip).

- According to the standard, the crm is signed (otherwise, there is no
meaning to the addition of the idPOPLinkWitness in the control section
of crm as described in 5.3.1). On the other side the full enrollment
request is signed, as described in section 4.2. In a case of renewal,
both signatures are required (the crm/pkcs10 are signed by the new key,
the whole message is signed by the old key). In the initial enrollment,
though, there is one redundant signature.

Avi
--
Avi Gozlan
Encryption Group, R&D
Check Point Software Tech. Ltd
e-mail: [email-masked]

---

From: J Adrian Pickering <[email-masked]>
Date: Wed, 06 Sep 2000 15:57:00 +0100

>standard open for other hash algorithms. Are there any plans to change

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?

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. What business is it of the TSA to 
know what it is stamping (semantically or syntactically)?

Adrian Pickering/
Electronics and Computer Science
University of Southampton
UK

---

From: "todd glassey" <[email-masked]>
Date: Mon, 11 Sep 2000 11:58:48 -0700

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

> of the AlgorithmIdentifier allows for a parameter which I'm not sure is
any

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.

> 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 analogus 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 hopw 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' on the other
hand . 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

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 ebents interchangable. 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.

What we need more than anything is a simple system that allows end users to,
with the transaction systems 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 differnt 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, doesnt 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 the IOTP/XML Receipt efforts at some level into the PKIX
Timestamping systems  and deliver evidentiary grade standards for all levels
of the transaction market. 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 componetns 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.

---

From: "todd glassey" <[email-masked]>
Date: Mon, 11 Sep 2000 12:06:41 -0700

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

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.

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.

represent a number of events interchangeably. There would need to be

"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!!!.

trust, the event it marks and the data components that make up that event,

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Sep 2000 19:12:17 -0400

Todd,

>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