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

From: [email-masked]
Date: Thu, 15 Jun 2000 13:08:14 -0400

Salut Denis,

Here are few comments on version 8, some a which are a repeat of previous
comments:

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

b.  In Section 2.4.2, the structure "PKIStatusInfo" is missing the OPTIONAL
"statusString" field, which is defined in RFC 2510 as PKIFreeText. Because
later in Section 2.4.2 it is mentioned that "The statusString field of
PKIStatusInfo MAY be used to include reason text such as 'messageImprint
field is not correctly formatted'", it would be preferable if the structure
"PKIStatusInfo" in this document was made consistent with the one in RFC
2510.

c.  Under Section 2.4.2, the structure "PKIStatus" can take the value of one
(1) (i.e. grantedWithMods), which is defined in RFC 2510 as:

         grantedWithMods        (1),
         -- you got something like what you asked for; the
         -- requester is responsible for ascertaining the differences

However, base on this definition from RFC 2510, it is not clear in the
context of a TSA if this means that a Time Stamp Token can be present, but
its format was modified from what the requester demanded. If so, some text
will need to be modified to also indicate that when the PKIStatus contains
the value one (1) and not just zero (0), a Time Stamp Token can also be
present. Otherwise, it should be clear what values for are allowed in the
structure "PKIStatus" of a response by a TSA. In this case, I would suggest
that you then indicate that the value of one (1) MUST not be used in a time
stamping response.

d.  Under Section 2.4.2, in the definition for the TSTInfo "policy" field,
it would be more meaningful to the requester if the document mandated that
the error "unacceptedPolicy (15)" be returned instead of the error
"badRequest (5)" when the TSA can not produce a response with a the same
policy as requested by the requester in the TimeStampReq.

e.  Since there is no "automated" way for a TSA announce to the world what
algorithms it supports to sign Time Stamp Tokens and also what algorithms it
supports in messageImprints although I had previously suggested using the
S/MIME
capabilities attribute for this, 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.

   Hash algorithm identifiers are located in the MessageImprint
   hashAlgorithm field, the [CMS] SignedData digestAlgorithms field and
   the [CMS] SignerInfo digestAlgorithm field.

   Hash values are located in the MessageImprint and the [CMS] Message
   Digest authenticated attribute.  In addition, hash values are input
   to signature algorithms.

4.1.1  SHA-1

   The SHA-1 hash algorithm is defined in FIPS Pub 180-1 [SHA1]. The
   algorithm identifier for SHA-1 is:

      sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
          oiw(14) secsig(3) algorithm(2) 26 }

   The AlgorithmIdentifier parameters field is optional.  If present,
   the parameters field must contain an ASN.1 NULL.  Implementations
   should accept SHA-1 AlgorithmIdentifiers with absent parameters as
   well as NULL parameters.  Implementations should generate SHA-1
   AlgorithmIdentifiers with NULL parameters.

4.1.2  MD5

   The MD5 hash algorithm is defined in RFC 1321 [MD5].  The algorithm
   identifier for MD5 is:

      md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
          rsadsi(113549) digestAlgorithm(2) 5 }

   The AlgorithmIdentifier parameters field must be present, and the
   parameters field must contain NULL.  Implementations may accept the
   MD5 AlgorithmIdentifiers with absent parameters as well as NULL
   parameters.

4.2  Signature Algorithms

   TSA implementations MUST support DSA.  TSA implementations MAY
   include RSA.

   Signature algorithm identifiers are located in the [CMS] SignerInfo
   signatureAlgorithm field.

   Signature values are located in the [CMS] SignerInfo signature
   field.

4.2.1  DSA

   The DSA signature algorithm is defined in FIPS Pub 186 [DSS].  DSA
   is always used with the SHA-1 message digest algorithm.  The
   algorithm identifier for DSA is:

      id-dsa-with-sha1 OBJECT IDENTIFIER ::=  { iso(1) member-body(2)
          us(840) x9-57 (10040) x9cm(4) 3 }

   The AlgorithmIdentifier parameters field must not be present.

4.2.2  RSA

   The RSA signature algorithm is defined in RFC 2347 [NEWPKCS#1]. RFC
   2347 specifies the use of the RSA signature algorithm with the SHA-1
   and MD5 message digest algorithms.  The algorithm identifier for RSA
   is:

      rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

f.  Under Section 6, you will have to add the [son of RFC 2459], which you
are now referring under Section 2.3 for the Subject Information Access
(SIA). You will also have to add all the references for the supported
algorithms (i.e. [SHA1], [MD5], [DSS] and [NEWPKCS#1]) if you agree to add
the new Section 4 above on Supported Algorithms.

Regards,

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

---

From: Joerg Seidel <[email-masked]>
Date: Thu, 15 Jun 2000 21:31:00 +0200

Comments inline.

> [email-masked] schrieb:
> 
Or just for performance purposes.

> I would then suggest that a new Section be

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.

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.

>    TSA implementations MUST support DSA.  TSA implementations MAY

Again I would do it the other way round: "TSA MUST support RSA. MAY support
DSA".

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: Paul Koning <[email-masked]>
Date: Mon, 19 Jun 2000 10:59:53 -0400 (EDT)

>>>>> "Joerg" == Joerg Seidel <[email-masked]> writes:

 Joerg> Comments inline.
 >> TSA implementations MUST support SHA-1.  TSA implementations
 >> SHOULD support MD5.

 Joerg> I think there are good reasons not to use MD5 in time
 Joerg> stamps. They should use a strong hash function in order to
 Joerg> achive long validity periods. MD5 is likely to be unsafe (=not
 Joerg> collision free) soon and is already discuraged by german
 Joerg> authorities.

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

IANAC, but from what I understand the currently known attacks on MD5
are nowhere near strong enough to justify that.  

I don't have a problem with the current text (SHA-1 required, MD5
recommended).  I do have a problem with text that implies that MD5 is
bad, because I don't know of data that supports such an assertion.

Also, it doesn't seem like a good idea for the timestamp spec to give
very different signals from the other security specs.  If there really
is good reason to say these kinds of things about MD5, let's have them
identified.  (German authorities are not a good reason.  Cryptanalysis
that shows weaknesses of interesting size would be.)  If the issues
are real, changes to MD5 text should be applied across the board.

      paul