Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

From: [email-masked]
Date: Fri, 16 Jun 2000 08:53:56 -0400

Jörg,

See comments inline.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

>-----Original Message-----
>From: Joerg Seidel [mailto:[email-masked]]
>Sent: Thursday, June 15, 2000 3:31 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
>
>Comments inline.
>
>> [email-masked] schrieb:
>> 
>> a.  Under Section 2.3, the first sentence indicates that "The TSA MUST
sign
>> all time stamp messages with one or more keys reserved specifically for
that
>> purpose". As suggested before, I would recommend that you add the
following
>> sentence after the first sentence to explain the reason(s) why a TSA
could
>> have more than one key reserved specifically for that purpose: "A TSA MAY
>> have more than one key to accommodate different policies, different
>> algorithms and/or different private key sizes".
>
>Or just for performance purposes.

If a TSA has more than one key for performance purposes, I would assume they
are just copies of the same private key cloned in different cryptographic
modules for performance and load balancing reasons. I think that the
document meant "distinct" private keys, but I would agree with you that it
is not obvious. Instead it could read this way:

"The TSA MUST sign all time stamp messages with one or more keys reserved
specifically for that purpose. A TSA MAY have distinct private keys to
accommodate different policies, different algorithms and/or different key
sizes."

>> I would then suggest that a new Section be
>> added between the current Sections 3 and 4, which would define the
minimum
>> set of algorithm that MUST and SHOULD be supported by requesters and
TSAs.
>> Based on Section 12 of RFC 2630 [CMS], it could read as follows:
>> 
>> 4  Supported Algorithms
>> 
>>    This section lists the algorithms that must be supported.
>>    Additional algorithms that should be supported are also included.
>> 
>> 4.1  Hash Algorithms
>> 
>>    TSA implementations MUST support SHA-1.  TSA implementations SHOULD
>>    support MD5.
>
>I think there are good reasons not to use MD5 in time stamps. They should
use
>a strong hash function in order to achive long validity periods. MD5 is
likely
>to be unsafe (=not collision free) soon and is already discuraged by german
>authorities.

I agree that TSAs should not use MD5 in their time stamps and MUST only use
strong hash functions (e.g. SHA-1, RIPEMD-160). However, there is nothing
wrong
for a requester to submit a message imprint containing a MD5 hash, which
means
that TSAs should be able accept request with MD5.

>IF we add a section about algorithms, it should maybe read: "TSA
>implementations MUST support SHA-1.  TSA implementations SHOULD NOT support
>MD5.". But I think such a section is not very necessary.

See comment above, however I agree that the text will have to be modified to
distinguish between the hash supported by TSAs in requests versus the hash
used by TSAs in time stamp tokens.

>> 4.2  Signature Algorithms
>> 
>>    TSA implementations MUST support DSA.  TSA implementations MAY
>>    include RSA.
>
>Again I would do it the other way round: "TSA MUST support RSA. MAY support
>DSA".

This came directly from RFC 2630 [CMS], however this document could mandate
different algorithms for TSA if this is what everyone agree.

>Jörg
>-- 
>__________________________________________________________________
>
>Jörg Seidel                             phone  +49-40-76629-1911
>Director Technology                     fax    +49-40-76629-551
>timeproof GmbH                          
>Harburger Schloßstraße 6-12             mailto:[email-masked]
>DE 21079 Hamburg                        http://www.timeproof.de
>__________________________________________________________________
>

---

From: Joerg Seidel <[email-masked]>
Date: Mon, 19 Jun 2000 11:24:22 +0200

Francois,

comments inline.

> modules for performance and load balancing reasons.

Since it is not possible with some cryptograpic modules to make copies of the
private key...

> accommodate different policies, different algorithms and/or different key

... I suggest:
"The TSA MUST sign all time stamp messages with one or more keys reserved
specifically for that purpose. A TSA MAY have distinct private keys to
accommodate different policies, different algorithms, different key
sizes and/or to increase the performance."

> that TSAs should be able accept request with MD5.

You are right. If a requester insists on using MD5 it is not up to the TSA to
explain him he shouldn't.

Joerg

---

From: Juergen Brauckmann <[email-masked]>
Date: Mon, 19 Jun 2000 11:24:37 +0200

>Since it is not possible with some cryptograpic modules to make copies of the

And sometimes not legal... .

Regards,
   Juergen

-- 
Juergen Brauckmann             Tel.:  040 / 8080 26 311
TC TrustCenter GmbH            Fax.:  040 / 8080 26 126
Sonninstraße 24-28   	    mailto:[email-masked]
20097 Hamburg 		    http://www.trustcenter.de

---

From: "Juergen Brauckmann" <[email-masked]>
Date: Mon, 19 Jun 2000 11:24:37 +0200

Regards,
   Juergen