Re: New test TSA available

pgut001@cs.auckland.ac.nz (Peter Gutmann) Wed, 22 August 2001 01:00 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04058 for <pkix-archive@odin.ietf.org>; Tue, 21 Aug 2001 21:00:00 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7M04T919230 for ietf-pkix-bks; Tue, 21 Aug 2001 17:04:29 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7M04RN19225 for <ietf-pkix@imc.org>; Tue, 21 Aug 2001 17:04:27 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id MAA05657; Wed, 22 Aug 2001 12:03:49 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz)
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id MAA281047; Wed, 22 Aug 2001 12:03:49 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz)
Date: Wed, 22 Aug 2001 12:03:49 +1200
Message-ID: <200108220003.MAA281047@ruru.cs.auckland.ac.nz>
From: pgut001@cs.auckland.ac.nz
To: pgut001@cs.auckland.ac.nz, tho@andxor.com
Subject: Re: New test TSA available
Cc: ietf-pkix@imc.org, r.galli@com-and.com
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

tho <tho@andxor.com> writes:

>(A) draft-ietf-pkix-time-stamp-15 states that eContentType for a time
>    stamping token should be id-ct-TSTInfo why is it instead set to
>    id-data ?

Probably because the implementation was done back when draft-06 or
something was current :-).  This is also why various other things
required by newer drafts aren't present, I'll fix this when I next
update the code (because of the environment it's in, there's a bit of
latency involved when making changes).

>since the encapsulated content type is set to id-data, version
>field in SignedData is (`correctly' since (A)) set to 1 and not to 3

This one's deliberate, since CMS implementations are split 50/50 between
ones which ignore the version entirely and ones which require it to be
what PKCS #7 set it to, I always use the PKCS #7 version value because
that means it'll work with everything.

>signatureAlgorithm in SignerInfo is rsaEncryption, shouldn't it be more
>likely sha1withRSAEncryption ?

Since the CMS signature splits the hash and signing algorithm, the first
OID is a pure hash (SHA-1) and the second is a pure signature algorithm
(RSA).

Peter.