Re: [ltans] RFC 3161 Token

Tobias Gondrom <tobias.gondrom@gondrom.org> Thu, 26 April 2012 17:20 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: ltans@ietfa.amsl.com
Delivered-To: ltans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E7121E8133 for <ltans@ietfa.amsl.com>; Thu, 26 Apr 2012 10:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.777
X-Spam-Level:
X-Spam-Status: No, score=-96.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hWR53eaolEv for <ltans@ietfa.amsl.com>; Thu, 26 Apr 2012 10:20:16 -0700 (PDT)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB3E21E812C for <ltans@ietf.org>; Thu, 26 Apr 2012 10:20:15 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ppfkxh3fG3WELD3/GM5wZG/ZH4KqI/tpQKjjkXepmA2F6J3l/DdFzgPn/V8UyF68mtRHo8hFBv+a3DapR9G5i1nRtPTCkvS8UCQiTJ7v2Fah+P6baFrJhYrfoOVQplsQ; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type;
Received: (qmail 10104 invoked from network); 26 Apr 2012 19:19:54 +0200
Received: from 113-28-26-162.static.imsbiz.com (HELO ?10.2.32.101?) (113.28.26.162) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Apr 2012 19:19:54 +0200
Message-ID: <4F9983B5.5080605@gondrom.org>
Date: Fri, 27 Apr 2012 01:19:49 +0800
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: ltans@ietf.org
References: <59E0E1DB40095E47AC604C81EE613F0C189D1EF3@mail.keyon.local>
In-Reply-To: <59E0E1DB40095E47AC604C81EE613F0C189D1EF3@mail.keyon.local>
Content-Type: multipart/alternative; boundary="------------030006000500020305080108"
Subject: Re: [ltans] RFC 3161 Token
X-BeenThere: ltans@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: LTANS Working Group <ltans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ltans>, <mailto:ltans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ltans>
List-Post: <mailto:ltans@ietf.org>
List-Help: <mailto:ltans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltans>, <mailto:ltans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Apr 2012 17:20:17 -0000

Hi,

yes it is the Time-Stamp Token and not the TimeStampResp, ....

And if I may say so, I think the RFC is pretty clear on that one in all 
sections:
e.g. " <TimeStamp> is REQUIRED and holds a <TimeStampToken> element with
       a Time-Stamp Token (as defined in Section 3.1.2) provided by the
       Time-Stamping Authority and an OPTIONAL element
<CryptographicInformationList>."

Please also take a read at section 3.1.2.

Regards, Tobias



On 26/04/12 23:14, Markus Isler wrote:
>
> Hi
>
> Just for clarification. For an RFC3161 type Time-Stamp Token, the 
> <TimeStamp>  element MUST contain base64 encoding of a DER-encoded 
> ASN1 data of TimeStampToken.
>
> TimeStampToken ::= ContentInfo
>
> And not the base64 encoding of a DER-encoded ASN1 data of TimeStampResp?
>
> TimeStampResp ::= SEQUENCE  {
>        status                  PKIStatusInfo,
>        timeStampToken          TimeStampToken     OPTIONAL  }
>
> Is that correct?
>
> Regards
>
> Markus
>
>
>
> _______________________________________________
> ltans mailing list
> ltans@ietf.org
> https://www.ietf.org/mailman/listinfo/ltans