From hatt3@otip.jp Fri Dec 18 03:50:40 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2234E3A682E for ; Fri, 18 Dec 2009 03:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCPfnSWOaKLI for ; Fri, 18 Dec 2009 03:50:39 -0800 (PST) Received: from auth.gate-on.net (auth.gate-on.net [210.197.72.170]) by core3.amsl.com (Postfix) with ESMTP id 0C8783A657C for ; Fri, 18 Dec 2009 03:50:38 -0800 (PST) Received: from otip.otip.jp (KD113159121125.ppp-bb.dion.ne.jp [113.159.121.125]) by auth.gate-on.net (Postfix) with ESMTP id 530129F151 for ; Fri, 18 Dec 2009 20:50:23 +0900 (JST) Received: from [192.168.0.2] (helo=localhost.localdomain) by otip.otip.jp with smtp (Exim 4.63) (envelope-from ) id 1NLbLj-0004DL-74 for ltans@ietf.org; Fri, 18 Dec 2009 20:50:23 +0900 Date: Fri, 18 Dec 2009 20:50:23 +0900 From: Satoru Otsubo To: ltans@ietf.org Message-Id: <20091218205023.b07176bc.hatt3@otip.jp> X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [ltans] Question about RFC 4998 Appendix A. Evidence Record Using CMS X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 11:55:18 -0000 I am Satoru Otsubo. Pardon me for my poor English. As ERS can give many CMS's a timestamp based on a hash tree and therefore the timestamp cost become very cheaper, I am considering to use ERS to timestamp many CMS's at once. RFC 4998 Appendix A has explanations to implement ERS on CMS's. (1) I want to give as an unsignedAttribute a Evidence Record to CMS which includes contentInfo. In this case, ASN.1 syntax of the unsignedAttribute is as follows?: Attribute ::= SEQUENCE { attrType OBJECT IDENTIFIER (1.2.840.113549.1.9.16.2.49) attrValues SET OF AttributeValue } AttributeValue ::= EvidenceRecord EvidenceRecord ::= SEQUENCE { version INTEGER { v1(1) } , digestAlgorithms SEQUENCE OF AlgorithmIdentifier, cryptoInfos [0] CryptoInfos OPTIONAL, encryptionInfo [1] EncryptionInfo OPTIONAL, archiveTimeStampSequence ArchiveTimeStampSequence } ............ ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, attributes [1] Attributes OPTIONAL, reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL, timeStamp ContentInfo} Namely, unsignedAttribute's OID is 1.2.840.113549.1.9.16.2.49 ? And, can I use as a AttributeValue the same EvidenceRecord syntax as described in RFC 4998 Section 3.1 and 4.1 ? (2) Well, 1.2.840.113549.1.9.16.2.49 is ASN.1 Internal EvidenceRecord Attribute. Therefore I think it can be used as a OID of any kind of selection method, as long as EvidenceRecord is included as an unsignedAttribute in CMS. Therefore I think it can be used not only as OID in selection method 1 and 2 described in Appendix A, but also as OID where signature is selected as selection method, as long as EvidenceRecord is included as an unsignedAttribute in CMS. Can I use 1.2.840.113549.1.9.16.2.49 when I use as data objects signatures of CMS ? SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, (<= I want to use this value as data object.) unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } Thanks in advance. From hatt3@otip.jp Sun Dec 20 02:52:20 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8113A680B for ; Sun, 20 Dec 2009 02:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=-0.892, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQX06q+omkUv for ; Sun, 20 Dec 2009 02:52:19 -0800 (PST) Received: from auth.gate-on.net (auth.gate-on.net [210.197.72.170]) by core3.amsl.com (Postfix) with ESMTP id 63B2D3A6808 for ; Sun, 20 Dec 2009 02:52:18 -0800 (PST) Received: from otip.otip.jp (KD113159121125.ppp-bb.dion.ne.jp [113.159.121.125]) by auth.gate-on.net (Postfix) with ESMTP id 8F46D9F13C for ; Sun, 20 Dec 2009 19:52:02 +0900 (JST) Received: from [192.168.0.2] (helo=localhost.localdomain) by otip.otip.jp with smtp (Exim 4.63) (envelope-from ) id 1NMJOM-00069V-Fb for ltans@ietf.org; Sun, 20 Dec 2009 19:52:02 +0900 Date: Sun, 20 Dec 2009 19:52:02 +0900 From: Satoru Otsubo To: ltans@ietf.org Message-Id: <20091220195202.1754dc1d.hatt3@otip.jp> X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [ltans] Question about RFC 4998 Section 4.2 Archive TimeStamp Generation X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 10:52:20 -0000 I am Satoru Otsubo. An example of a constructed hash tree for 3 data groups is presented at RFC 4998 Section 4.2. Here is a copy of Figure 1. h123 x xxxxxxxxxxxxxxxxxxx x x x x h12 x x x xxxxxxxxxxxxx x x x x x x x h1 h2abc h3 x xxxxxxxxxxx x x x x x x h2a h2b h2c ( Figure 1 ) And, the reduced hash tree rht1 for data group 1 is shown as follows: ( ( h2abc h1 ) ( h3 ) ) ( Figure 2 (simplified)) rht1 = SEQ(pht1,pht2), where pht1 = SEQ(h2abc, h1), and pht2 = SEQ(h3) But I think the reduced hash tree rht1 for data group 1 is preferably the following. ( ( h1 ) ( h2abc ) ( h3 ) ) rht1 = SEQ(pht1,pht2,pht3), where pht1 = SEQ(h1), pht2 = SEQ(h2abc), and pht3 = SEQ(h3) That is, any of partialHashTrees includes only one hash and data group 1 is placed at the first partialHashTree. On verification, I think, (1) h1 and h2abc are binary sorted, concatinated and hashed, then, (2) the result of (1) and h3 are binary sorted, concatinated and hashed. Why in RFC 4998 Section 4.2, are h2abc and h1 gathered as a partialHashTree ? And why h2abc and h1 are binary sorted in advance and h1 is placed at the second position in a partialHashTree, assuming the binary ordering is h2abc

X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293553A680B for ; Sun, 20 Dec 2009 02:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGS5MhPqeHbT for ; Sun, 20 Dec 2009 02:53:22 -0800 (PST) Received: from auth.gate-on.net (auth.gate-on.net [210.197.72.170]) by core3.amsl.com (Postfix) with ESMTP id 35EC13A6808 for ; Sun, 20 Dec 2009 02:53:22 -0800 (PST) Received: from otip.otip.jp (KD113159121125.ppp-bb.dion.ne.jp [113.159.121.125]) by auth.gate-on.net (Postfix) with ESMTP id BE3959F13B for ; Sun, 20 Dec 2009 19:53:06 +0900 (JST) Received: from [192.168.0.2] (helo=localhost.localdomain) by otip.otip.jp with smtp (Exim 4.63) (envelope-from ) id 1NMJPO-00069m-MI for ltans@ietf.org; Sun, 20 Dec 2009 19:53:06 +0900 Date: Sun, 20 Dec 2009 19:53:06 +0900 From: Satoru Otsubo To: ltans@ietf.org Message-Id: <20091220195306.a9eac454.hatt3@otip.jp> X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [ltans] Question about RFC 4998 Section 4.2 Archive TimeStamp Generation X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 10:53:23 -0000 I am Satoru Otsubo. In RFC 4998, Section 4.2 Generation, stage 4., there is the following explanation (Page 13, line 1-3): (If additional hash values are needed, e.g., so that all nodes have the same number of children, any data may be hashed using H and used.) But I think, if one node is build from two nodes, no additional hash values are needed. For example, (a) h123 x xxxxxxxxxxxxxxxxxxx x x x x h12 x x x xxxxxxxxxxxxx x x x x x x x h1 h2 h3 (b) h1234 x xxxxxxxxxxxxxxxxxxxxxxxxx x x x x h12 h34 x x xxxxxxxxxxxxx xxxxxxxxxxxx x x x x x x x x h1 h2 h3 h4 (c) h12345 x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x x x x h1234 x x x xxxxxxxxxxxxxxxxxxxxxxxxx x x x x x x x h12 h34 x x x x xxxxxxxxxxxxx xxxxxxxxxxxx x x x x x x x x x x x h1 h2 h3 h4 h5 (d) h123456 x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x x x x h1234 x x x xxxxxxxxxxxxxxxxxxxxxxxxx x x x x x x x h12 h34 h56 x x x xxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxx x x x x x x x x x x x x h1 h2 h3 h4 h5 h6 As shown fig(a),(b),(c),(d), despite the number of datagroups (leaves), a root node seems to be always build without additional hash values, as long as one node is build from two nodes. What situation is imagined as a case where additional hash values are needed ? Thanks in advance. From hatt3@otip.jp Sun Dec 20 19:03:45 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5AA33A6805 for ; Sun, 20 Dec 2009 19:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQOzBsBgsW5m for ; Sun, 20 Dec 2009 19:03:45 -0800 (PST) Received: from auth.gate-on.net (auth.gate-on.net [210.197.72.170]) by core3.amsl.com (Postfix) with ESMTP id F0EC13A67A8 for ; Sun, 20 Dec 2009 19:03:44 -0800 (PST) Received: from otip.otip.jp (KD113159121125.ppp-bb.dion.ne.jp [113.159.121.125]) by auth.gate-on.net (Postfix) with ESMTP id 294969F14F for ; Mon, 21 Dec 2009 12:03:28 +0900 (JST) Received: from [192.168.0.2] (helo=localhost.localdomain) by otip.otip.jp with smtp (Exim 4.63) (envelope-from ) id 1NMYYS-0006oo-2Q for ltans@ietf.org; Mon, 21 Dec 2009 12:03:28 +0900 Date: Mon, 21 Dec 2009 12:03:28 +0900 From: Satoru Otsubo Cc: ltans@ietf.org Message-Id: <20091221120328.fa3c2c64.hatt3@otip.jp> X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [ltans] Question about the hash against a single data object in RFC 4998 X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 03:03:46 -0000 I am Satoru Otsubo. RFC 4998 Section 4.1 describes as follows (Page 12, line 16-18): "If the optional field reducedHashtree is not present, the Archive Timestamp simply contains an ordinary timestamp." >From this statement, I understand that if the digestAlgorithm designated in Archive Timestamp and the hashAlgorithm designated in the timestamp request are same, then we hash a data object (assuming a single data object need to be timestamped) with the digestAlgorithm ( = the hashAlgorithm) and send its result to the TSA. Namely, Only one hash is executed against a data object. But if the digestAlgorithm designated in Archive Timestamp and the hashAlgorithm designated in the timestamp request are not same, then do we have to hash a data object with the digestAlgorithm designated in Archive Timestamp and then hash its result with the hashAlgorithm designated in the timestamp request ? (as described in http://www.imc.org/ietf-ltans/mail-archive/msg00824.html) Therefore hash is executed twice against a data object ? Thanks in advance.