From isler@keyon.ch Wed Apr 25 01:42:00 2012 Return-Path: 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 051A721F86F7 for ; Wed, 25 Apr 2012 01:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] 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 D7+0Z8g6z4Zy for ; Wed, 25 Apr 2012 01:41:59 -0700 (PDT) Received: from keyon.ch (keyon.ch [91.193.21.20]) by ietfa.amsl.com (Postfix) with SMTP id 1927B21F86E5 for ; Wed, 25 Apr 2012 01:41:58 -0700 (PDT) Received: (qmail 6308 invoked from network); 25 Apr 2012 08:42:09 -0000 Received: from keyon.ch (91.193.21.20) by keyon.ch with QMTP; 25 Apr 2012 08:42:09 -0000 Received: (qmail 2429 invoked from network); 25 Apr 2012 08:41:23 -0000 Received: from mail.keyon.local (10.20.0.25) by gateway.keyon.local with SMTP; 25 Apr 2012 08:41:23 -0000 Received: from MAIL.keyon.local ([fe80::7d9f:46c8:e003:9d25]) by mail.keyon.local ([fe80::7d9f:46c8:e003:9d25%11]) with mapi id 14.01.0355.002; Wed, 25 Apr 2012 10:41:21 +0200 From: Markus Isler To: "ltans@ietf.org" Thread-Topic: Canonicalization Thread-Index: Ac0ivfP69AnWd5RsRQCooLTigEkPgA== Date: Wed, 25 Apr 2012 08:41:20 +0000 Message-ID: <59E0E1DB40095E47AC604C81EE613F0C189D1803@mail.keyon.local> Accept-Language: de-CH, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.21] Content-Type: multipart/alternative; boundary="_000_59E0E1DB40095E47AC604C81EE613F0C189D1803mailkeyonlocal_" MIME-Version: 1.0 Subject: [ltans] Canonicalization X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 09:05:00 -0000 --_000_59E0E1DB40095E47AC604C81EE613F0C189D1803mailkeyonlocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I have a question regarding Canonicalization of XML elements. According to = 3.2.2 archive data has to be canonicalized before hashing it. Supposed we are archiving files of arbitrary format. Does this mean that we= have check each file whether it is a valid XML file? I hope this is not th= e case. Regards Markus --_000_59E0E1DB40095E47AC604C81EE613F0C189D1803mailkeyonlocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

I have a question regarding Can= onicalization of XML elements. According to 3.2.2 archive data has to be ca= nonicalized before hashing it.

 

Supposed we are archiving files= of arbitrary format. Does this mean that we have check each file whether i= t is a valid XML file? I hope this is not the case.

 

Regards

Markus  =

 

--_000_59E0E1DB40095E47AC604C81EE613F0C189D1803mailkeyonlocal_-- From tobias.gondrom@gondrom.org Thu Apr 26 03:03:25 2012 Return-Path: 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 7F09921F86AB for ; Thu, 26 Apr 2012 03:03:25 -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 A3dkUAOvSgmL for ; Thu, 26 Apr 2012 03:03:24 -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 294B721F8674 for ; Thu, 26 Apr 2012 03:03:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=amy8pTCX28FAiWEbI6skXyKTLp05huKQAYh3j6j/eN4xVHZBNA3qRnF8XIRz8JvleVsTt9acJ5Ua0OJADEMFXUdjwz2/2xYyIe6A9Q08lCv5dXF+lG9heyqBiyrKIa30; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; Received: (qmail 7264 invoked from network); 26 Apr 2012 12:02:30 +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 12:02:29 +0200 Message-ID: <4F991D31.7040207@gondrom.org> Date: Thu, 26 Apr 2012 18:02:25 +0800 From: Tobias Gondrom 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: <59E0E1DB40095E47AC604C81EE613F0C189D1803@mail.keyon.local> In-Reply-To: <59E0E1DB40095E47AC604C81EE613F0C189D1803@mail.keyon.local> Content-Type: multipart/alternative; boundary="------------090406080003000507090905" Subject: Re: [ltans] Canonicalization X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:03:25 -0000 This is a multi-part message in MIME format. --------------090406080003000507090905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Markus, actually section 3.2.2 is referring to the Reduction of Hash Tree. From you question I assume you meant to refer to section 3.2 item 2. Please be advised, that if you store archive objects in XML data without canonicalization, you have a significant risk that the order of elements may be rearranged by parsers when read/edited and the bit representation of the data may change and will therefor no longer correspond to previously calculated hash values. Therefore it is important to make sure XML data is canonicalized before it enters the system. Mainly consider scenarios where a client may want to intergrate the XMLERS into the same XML data structure and later obviously must remove it from the structure before it can be verified. (on a side note: btw. pure XML data format alone is in general suboptimal for long-term non-repudiation of documents, as it may also require stylesheets to achieve reproducible representation of the data.) So if you put XML data into the system and want to use some of the special properties of XML (i.e. allowing to integrate the XMLERS afterwards into the XML document itself and removing it prior to verification) you MUST canonicalize it to make sure your bit representation will always remain consistent after these operations. However, from a technical perspective you can equally treat it as a data blob (agnostic to the format). So you can treat it as bits and bytes unaware of any file format. Best regards, Tobias On 25/04/12 16:41, Markus Isler wrote: > > Hi > > I have a question regarding Canonicalization of XML elements. > According to 3.2.2 archive data has to be canonicalized before hashing it. > > Supposed we are archiving files of arbitrary format. Does this mean > that we have check each file whether it is a valid XML file? I hope > this is not the case. > > Regards > > Markus > > > > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans --------------090406080003000507090905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Markus,

actually section 3.2.2 is referring to the Reduction of Hash Tree. From you question I assume you meant to refer to section 3.2 item 2.

Please be advised, that if you store archive objects in XML data without canonicalization, you have a significant risk that the order of elements may be rearranged by parsers when read/edited and the bit representation of the data may change and will therefor no longer correspond to previously calculated hash values.
Therefore it is important to make sure XML data is canonicalized before it enters the system. Mainly consider scenarios where a client may want to intergrate the XMLERS into the same XML data structure and later obviously must remove it from the structure before it can be verified.
(on a side note: btw. pure XML data format alone is in general suboptimal for long-term non-repudiation of documents, as it may also require stylesheets to achieve reproducible representation of the data.)

So if you put XML data into the system and want to use some of the special properties of XML (i.e. allowing to integrate the XMLERS afterwards into the XML document itself and removing it prior to verification) you MUST canonicalize it to make sure your bit representation will always remain consistent after these operations.

However, from a technical perspective you can equally treat it as a data blob (agnostic to the format). So you can treat it as bits and bytes unaware of any file format.

Best regards, Tobias




On 25/04/12 16:41, Markus Isler wrote:

Hi

 

I have a question regarding Canonicalization of XML elements. According to 3.2.2 archive data has to be canonicalized before hashing it.

 

Supposed we are archiving files of arbitrary format. Does this mean that we have check each file whether it is a valid XML file? I hope this is not the case.

 

Regards

Markus  

 



_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans

--------------090406080003000507090905-- From isler@keyon.ch Thu Apr 26 06:31:09 2012 Return-Path: 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 ADF6E21F8598 for ; Thu, 26 Apr 2012 06:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 sFxKHqwIluNU for ; Thu, 26 Apr 2012 06:31:03 -0700 (PDT) Received: from keyon.ch (keyon.ch [91.193.21.20]) by ietfa.amsl.com (Postfix) with SMTP id 04A2F21F85A4 for ; Thu, 26 Apr 2012 06:31:02 -0700 (PDT) Received: (qmail 11385 invoked from network); 26 Apr 2012 13:31:20 -0000 Received: from keyon.ch (91.193.21.20) by keyon.ch with QMTP; 26 Apr 2012 13:31:20 -0000 Received: (qmail 27395 invoked from network); 26 Apr 2012 13:30:51 -0000 Received: from mail.keyon.local (10.20.0.25) by gateway.keyon.local with SMTP; 26 Apr 2012 13:30:51 -0000 Received: from MAIL.keyon.local ([fe80::7d9f:46c8:e003:9d25]) by mail.keyon.local ([fe80::7d9f:46c8:e003:9d25%11]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 15:30:48 +0200 From: Markus Isler To: "ltans@ietf.org" Thread-Topic: [ltans] Canonicalization Thread-Index: Ac0ivfP69AnWd5RsRQCooLTigEkPgAAxPZ+AAAlvUXA= Date: Thu, 26 Apr 2012 13:30:46 +0000 Message-ID: <59E0E1DB40095E47AC604C81EE613F0C189D1DB3@mail.keyon.local> References: <59E0E1DB40095E47AC604C81EE613F0C189D1803@mail.keyon.local> <4F991D31.7040207@gondrom.org> In-Reply-To: <4F991D31.7040207@gondrom.org> Accept-Language: de-CH, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.21] Content-Type: multipart/alternative; boundary="_000_59E0E1DB40095E47AC604C81EE613F0C189D1DB3mailkeyonlocal_" MIME-Version: 1.0 Subject: Re: [ltans] Canonicalization X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 13:31:10 -0000 --_000_59E0E1DB40095E47AC604C81EE613F0C189D1DB3mailkeyonlocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tobias Yes 3.2. item 2. Sorry for the confusion and thanks for clarification. I understand that it makes sense to canonicalize XML data if you integrate = XMLERS into to XML structure you archived. This is similar to XMLDSIG. Howe= ver XMLDSIG allows XML input only where XMLERS allows any input format like= RFC 4998. Processing XMLDSIG input data is very clear. If it cannot be XML= parsed it is invalid. Processing RFC 4998 input data is also clear as the = input is a binary blob and I don't care about its format. XMLERS is tricky= because if I strictly follow the RFC 6283 a "canonicalization method MUST = be used also for archive data when data is represented in XML format". As y= ou mentioned before I can technically treat every input as binary blob unaw= are of the format of the data. In this case XML data is not canonicalized. = I am pretty sure that this leads to compatibility problems. I wonder how ot= hers that implement XMLERS deal with that. Best regards Markus From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf Of T= obias Gondrom Sent: Donnerstag, 26. April 2012 12:02 To: ltans@ietf.org Subject: Re: [ltans] Canonicalization Hi Markus, actually section 3.2.2 is referring to the Reduction of Hash Tree. From you= question I assume you meant to refer to section 3.2 item 2. Please be advised, that if you store archive objects in XML data without ca= nonicalization, you have a significant risk that the order of elements may = be rearranged by parsers when read/edited and the bit representation of the= data may change and will therefor no longer correspond to previously calcu= lated hash values. Therefore it is important to make sure XML data is canonicalized before it = enters the system. Mainly consider scenarios where a client may want to int= ergrate the XMLERS into the same XML data structure and later obviously mus= t remove it from the structure before it can be verified. (on a side note: btw. pure XML data format alone is in general suboptimal f= or long-term non-repudiation of documents, as it may also require styleshee= ts to achieve reproducible representation of the data.) So if you put XML data into the system and want to use some of the special = properties of XML (i.e. allowing to integrate the XMLERS afterwards into th= e XML document itself and removing it prior to verification) you MUST canon= icalize it to make sure your bit representation will always remain consiste= nt after these operations. However, from a technical perspective you can equally treat it as a data bl= ob (agnostic to the format). So you can treat it as bits and bytes unaware = of any file format. Best regards, Tobias On 25/04/12 16:41, Markus Isler wrote: Hi I have a question regarding Canonicalization of XML elements. According to = 3.2.2 archive data has to be canonicalized before hashing it. Supposed we are archiving files of arbitrary format. Does this mean that we= have check each file whether it is a valid XML file? I hope this is not th= e case. Regards Markus _______________________________________________ ltans mailing list ltans@ietf.org https://www.ietf.org/mailman/listinfo/ltans --_000_59E0E1DB40095E47AC604C81EE613F0C189D1DB3mailkeyonlocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tobias

 

Yes&nbs= p; 3.2. item 2. Sorry for the confusion and thanks for clarification.<= /o:p>

&n= bsp;

I under= stand that it makes sense to canonicalize XML data if you integrate XMLERS = into to XML structure you archived. This is similar to XMLDSIG. However XML= DSIG allows XML input only where XMLERS allows any input format like RFC 4998. Processing XMLDSIG input data is ve= ry clear. If it cannot be XML parsed it is invalid. Processing RFC 4998 inp= ut data is also clear as the input is a binary blob and I don’t care = about its format.  XMLERS is tricky because if I strictly follow the RFC 6283 a “canonicalization method MUST be= used also for archive data when data is represented in XML format”. = As you mentioned before I can technically treat every input as binary blob = unaware of the format of the data. In this case XML data is not canonicalized. I am pretty sure that this leads to compati= bility problems. I wonder how others that implement XMLERS deal with that.<= o:p>

&n= bsp;

Best re= gards

Markus<= o:p>

&n= bsp;

&n= bsp;

From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf Of Tobias Gondrom
Sent: Donnerstag, 26. April 2012 12:02
To: ltans@ietf.org
Subject: Re: [ltans] Canonicalization

 

Hi Markus,

actually section 3.2.2 is referring to the Reduction of Hash Tree. From you= question I assume you meant to refer to section 3.2 item 2.

Please be advised, that if you store archive objects in XML data without ca= nonicalization, you have a significant risk that the order of elements may = be rearranged by parsers when read/edited and the bit representation of the= data may change and will therefor no longer correspond to previously calculated hash values.
Therefore it is important to make sure XML data is canonicalized before it = enters the system. Mainly consider scenarios where a client may want to int= ergrate the XMLERS into the same XML data structure and later obviously mus= t remove it from the structure before it can be verified.
(on a side note: btw. pure XML data format alone is in general suboptimal f= or long-term non-repudiation of documents, as it may also require styleshee= ts to achieve reproducible representation of the data.)

So if you put XML data into the system and want to use some of the special = properties of XML (i.e. allowing to integrate the XMLERS afterwards into th= e XML document itself and removing it prior to verification) you MUST canon= icalize it to make sure your bit representation will always remain consistent after these operations.

However, from a technical perspective you can equally treat it as a data bl= ob (agnostic to the format). So you can treat it as bits and bytes unaware = of any file format.

Best regards, Tobias




On 25/04/12 16:41, Markus Isler wrote:

Hi

 

I have a question regarding Can= onicalization of XML elements. According to 3.2.2 archive data has to be ca= nonicalized before hashing it.

 

Supposed we are archiving files= of arbitrary format. Does this mean that we have check each file whether i= t is a valid XML file? I hope this is not the case.

 

Regards

Markus  =

 




_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ie=
tf.org/mailman/listinfo/ltans

&nbs= p;

--_000_59E0E1DB40095E47AC604C81EE613F0C189D1DB3mailkeyonlocal_-- From isler@keyon.ch Thu Apr 26 08:15:03 2012 Return-Path: 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 6865321E8092 for ; Thu, 26 Apr 2012 08:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 oM5p8heVpkrF for ; Thu, 26 Apr 2012 08:15:02 -0700 (PDT) Received: from keyon.ch (keyon.ch [91.193.21.20]) by ietfa.amsl.com (Postfix) with SMTP id 0C2F221E808D for ; Thu, 26 Apr 2012 08:15:01 -0700 (PDT) Received: (qmail 13630 invoked from network); 26 Apr 2012 15:15:23 -0000 Received: from keyon.ch (91.193.21.20) by keyon.ch with QMTP; 26 Apr 2012 15:15:23 -0000 Received: (qmail 31351 invoked from network); 26 Apr 2012 15:14:03 -0000 Received: from mail.keyon.local (10.20.0.25) by gateway.keyon.local with SMTP; 26 Apr 2012 15:14:03 -0000 Received: from MAIL.keyon.local ([fe80::7d9f:46c8:e003:9d25]) by mail.keyon.local ([fe80::7d9f:46c8:e003:9d25%11]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 17:14:02 +0200 From: Markus Isler To: "ltans@ietf.org" Thread-Topic: RFC 3161 Token Thread-Index: Ac0jvLGIEVYdYKHkS7KY4E8wUkDeSQ== Date: Thu, 26 Apr 2012 15:14:02 +0000 Message-ID: <59E0E1DB40095E47AC604C81EE613F0C189D1EF3@mail.keyon.local> Accept-Language: de-CH, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.21] Content-Type: multipart/alternative; boundary="_000_59E0E1DB40095E47AC604C81EE613F0C189D1EF3mailkeyonlocal_" MIME-Version: 1.0 Subject: [ltans] RFC 3161 Token X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:15:03 -0000 --_000_59E0E1DB40095E47AC604C81EE613F0C189D1EF3mailkeyonlocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Just for clarification. For an RFC3161 type Time-Stamp Token, the element MUST contain base64 encoding of a DER-encoded ASN1 data of Time= StampToken. TimeStampToken ::=3D ContentInfo And not the base64 encoding of a DER-encoded ASN1 data of TimeStampResp? TimeStampResp ::=3D SEQUENCE { status PKIStatusInfo, timeStampToken TimeStampToken OPTIONAL } Is that correct? Regards Markus --_000_59E0E1DB40095E47AC604C81EE613F0C189D1EF3mailkeyonlocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

Just for clarification. For an = RFC3161 type Time-Stamp Token, the <TimeStamp>  element MUST con= tain base64 encoding of a DER-encoded ASN1 data of TimeStampToken.

 

TimeStampToken ::=3D ContentInf= o

 

And not the base64 encoding of = a DER-encoded ASN1 data of TimeStampResp?

 

TimeStampResp ::=3D SEQUENCE  {
      status  =
            &nb=
sp;   PKIStatusInfo,
      timeStampToken&nbs=
p;         TimeStampToken &nbs=
p;   OPTIONAL  }

 

Is that correct?

 

Regards

Markus

--_000_59E0E1DB40095E47AC604C81EE613F0C189D1EF3mailkeyonlocal_-- From tobias.gondrom@gondrom.org Thu Apr 26 10:20:17 2012 Return-Path: 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 ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 17:20:17 -0000 This is a multi-part message in MIME format. --------------030006000500020305080108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. " is REQUIRED and holds a element with a Time-Stamp Token (as defined in Section 3.1.2) provided by the Time-Stamping Authority and an OPTIONAL element ." 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 > 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 --------------030006000500020305080108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

--------------030006000500020305080108-- From isler@keyon.ch Thu Apr 26 11:17:59 2012 Return-Path: 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 E607421E8107 for ; Thu, 26 Apr 2012 11:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 3INp9did2Omp for ; Thu, 26 Apr 2012 11:17:58 -0700 (PDT) Received: from keyon.ch (keyon.ch [91.193.21.20]) by ietfa.amsl.com (Postfix) with SMTP id 54A9621E80A1 for ; Thu, 26 Apr 2012 11:17:57 -0700 (PDT) Received: (qmail 16633 invoked from network); 26 Apr 2012 18:18:24 -0000 Received: from keyon.ch (91.193.21.20) by keyon.ch with QMTP; 26 Apr 2012 18:18:24 -0000 Received: (qmail 4611 invoked from network); 26 Apr 2012 18:17:17 -0000 Received: from mail.keyon.local (10.20.0.25) by gateway.keyon.local with SMTP; 26 Apr 2012 18:17:17 -0000 Received: from MAIL.keyon.local ([fe80::7d9f:46c8:e003:9d25]) by mail.keyon.local ([fe80::7d9f:46c8:e003:9d25%11]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 20:17:11 +0200 From: Markus Isler To: "ltans@ietf.org" Thread-Topic: [ltans] RFC 3161 Token Thread-Index: Ac0jvLGIEVYdYKHkS7KY4E8wUkDeSQAA1OSAAAYx0XA= Date: Thu, 26 Apr 2012 18:17:11 +0000 Message-ID: References: <59E0E1DB40095E47AC604C81EE613F0C189D1EF3@mail.keyon.local>, <4F9983B5.5080605@gondrom.org> In-Reply-To: <4F9983B5.5080605@gondrom.org> Accept-Language: de-CH, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A42A925F00DF47858E149699C934227Dkeyonch_" MIME-Version: 1.0 Subject: Re: [ltans] RFC 3161 Token X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:17:59 -0000 --_000_A42A925F00DF47858E149699C934227Dkeyonch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tobias Thanks for clarifying. Regards Markus Am 26.04.2012 um 19:20 schrieb "Tobias Gondrom" >: 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 sec= tions: e.g. " is REQUIRED and holds a element wi= th a Time-Stamp Token (as defined in Section 3.1.2) provided by the Time-Stamping Authority and an OPTIONAL element ." 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 element MUST contain base64 encoding of a DER-encoded ASN1 data of Time= StampToken. TimeStampToken ::=3D ContentInfo And not the base64 encoding of a DER-encoded ASN1 data of TimeStampResp? TimeStampResp ::=3D SEQUENCE { status PKIStatusInfo, timeStampToken TimeStampToken OPTIONAL } Is that correct? Regards Markus _______________________________________________ ltans mailing list ltans@ietf.org https://www.ietf.org/mailman/listinfo/ltans _______________________________________________ ltans mailing list ltans@ietf.org https://www.ietf.org/mailman/listinfo/ltans --_000_A42A925F00DF47858E149699C934227Dkeyonch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Tobias

Thanks for clarifying.

Regards
Markus


Am 26.04.2012 um 19:20 schrieb "Tobias Gondrom" <tobias.gondrom@gondrom.org>:

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 sec= tions:
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 elem= ent
      <CryptographicInformationList>."<= br>
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 con= tain base64 encoding of a DER-encoded ASN1 data of TimeStampToken.

 

TimeStampToken ::=3D Cont= entInfo

 

And not the base64 encoding of = a DER-encoded ASN1 data of TimeStampResp?

 

TimeStampResp ::=3D SEQUENCE  {
      status  =
            &nb=
sp;   PKIStatusInfo,
      timeStampToken&nbs=
p;         TimeStampToken &nbs=
p;   OPTIONAL  }

 

Is that correct?

 

Regards

Markus



_______________________________________________
ltans mailing list
ltans@=
ietf.org
https://www.ietf.org/mailman/listinfo/ltans

_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.i= etf.org/mailman/listinfo/ltans
--_000_A42A925F00DF47858E149699C934227Dkeyonch_-- From isler@keyon.ch Thu Apr 26 11:17:59 2012 Return-Path: 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 B764B21E8103 for ; Thu, 26 Apr 2012 11:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 E01V9Tg7nYmn for ; Thu, 26 Apr 2012 11:17:58 -0700 (PDT) Received: from keyon.ch (keyon.ch [91.193.21.20]) by ietfa.amsl.com (Postfix) with SMTP id 54AE521E80F2 for ; Thu, 26 Apr 2012 11:17:57 -0700 (PDT) Received: (qmail 16630 invoked from network); 26 Apr 2012 18:18:24 -0000 Received: from keyon.ch (91.193.21.20) by keyon.ch with QMTP; 26 Apr 2012 18:18:24 -0000 Received: (qmail 4611 invoked from network); 26 Apr 2012 18:17:17 -0000 Received: from mail.keyon.local (10.20.0.25) by gateway.keyon.local with SMTP; 26 Apr 2012 18:17:17 -0000 Received: from MAIL.keyon.local ([fe80::7d9f:46c8:e003:9d25]) by mail.keyon.local ([fe80::7d9f:46c8:e003:9d25%11]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 20:17:11 +0200 From: Markus Isler To: "ltans@ietf.org" Thread-Topic: [ltans] RFC 3161 Token Thread-Index: Ac0jvLGIEVYdYKHkS7KY4E8wUkDeSQAA1OSAAAYx0XA= Date: Thu, 26 Apr 2012 18:17:11 +0000 Message-ID: References: <59E0E1DB40095E47AC604C81EE613F0C189D1EF3@mail.keyon.local>, <4F9983B5.5080605@gondrom.org> In-Reply-To: <4F9983B5.5080605@gondrom.org> Accept-Language: de-CH, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A42A925F00DF47858E149699C934227Dkeyonch_" MIME-Version: 1.0 Subject: Re: [ltans] RFC 3161 Token X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:17:59 -0000 --_000_A42A925F00DF47858E149699C934227Dkeyonch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tobias Thanks for clarifying. Regards Markus Am 26.04.2012 um 19:20 schrieb "Tobias Gondrom" >: 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 sec= tions: e.g. " is REQUIRED and holds a element wi= th a Time-Stamp Token (as defined in Section 3.1.2) provided by the Time-Stamping Authority and an OPTIONAL element ." 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 element MUST contain base64 encoding of a DER-encoded ASN1 data of Time= StampToken. TimeStampToken ::=3D ContentInfo And not the base64 encoding of a DER-encoded ASN1 data of TimeStampResp? TimeStampResp ::=3D SEQUENCE { status PKIStatusInfo, timeStampToken TimeStampToken OPTIONAL } Is that correct? Regards Markus _______________________________________________ ltans mailing list ltans@ietf.org https://www.ietf.org/mailman/listinfo/ltans _______________________________________________ ltans mailing list ltans@ietf.org https://www.ietf.org/mailman/listinfo/ltans --_000_A42A925F00DF47858E149699C934227Dkeyonch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Tobias

Thanks for clarifying.

Regards
Markus


Am 26.04.2012 um 19:20 schrieb "Tobias Gondrom" <tobias.gondrom@gondrom.org>:

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 sec= tions:
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 elem= ent
      <CryptographicInformationList>."<= br>
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 con= tain base64 encoding of a DER-encoded ASN1 data of TimeStampToken.

 

TimeStampToken ::=3D Cont= entInfo

 

And not the base64 encoding of = a DER-encoded ASN1 data of TimeStampResp?

 

TimeStampResp ::=3D SEQUENCE  {
      status  =
            &nb=
sp;   PKIStatusInfo,
      timeStampToken&nbs=
p;         TimeStampToken &nbs=
p;   OPTIONAL  }

 

Is that correct?

 

Regards

Markus



_______________________________________________
ltans mailing list
ltans@=
ietf.org
https://www.ietf.org/mailman/listinfo/ltans

_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.i= etf.org/mailman/listinfo/ltans
--_000_A42A925F00DF47858E149699C934227Dkeyonch_--