[smime] FW: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt
"Peter Rybar" <rybar@nbusr.sk> Wed, 21 October 2009 10:09 UTC
Return-Path: <rybar@nbusr.sk>
X-Original-To: smime@core3.amsl.com
Delivered-To: smime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327013A67F8 for <smime@core3.amsl.com>; Wed, 21 Oct 2009 03:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.352
X-Spam-Level: *
X-Spam-Status: No, score=1.352 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001]
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 6O-6fSc1+peq for <smime@core3.amsl.com>; Wed, 21 Oct 2009 03:09:43 -0700 (PDT)
Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by core3.amsl.com (Postfix) with ESMTP id 77EAA3A67DF for <smime@ietf.org>; Wed, 21 Oct 2009 03:09:40 -0700 (PDT)
From: Peter Rybar <rybar@nbusr.sk>
To: smime@ietf.org
Date: Wed, 21 Oct 2009 12:10:21 +0200
Message-ID: <200910211009.n9LA9lkb016103@mail.nbusr.sk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01CA5247.76764AE0"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcpRXKfyyU3/hl/9dkWptEJRifJH1QAvtWXgAAbDbdA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
X-NAI-Spam-Score: 0
X-NAI-Spam-Report: 1 Rules triggered * 0 -- RV3387 -- BODY: Version number
Subject: [smime] FW: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt
X-BeenThere: smime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SMIME Working Group <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smime>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2009 10:09:44 -0000
From: Peter Rybar [mailto:rybar@nbusr.sk] Sent: Wednesday, October 21, 2009 11:41 AM To: 'pkix@ietf.org' Cc: 'ietf-smime@ietf.org'; 'ESI@list.etsi.org'; 'peterryb@gmail.com' Subject: RE: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt Dear all, The pkix-bounces@ietf.org timestamp discussion about allowing to use ESSCertIDv2 (defined in RFC 5035) together with presently used mandatory ESSCertID(SHA1) in timestamp causes a confusion. For example at one important meeting, an expert from one EU country presented that he was incorrectly informed that the usage of ESSCertID or ESSCertIDv2 is useful only for solving of the hypothetical attack which is not possible in reality and mentioned that it was the opinion of IETF and ETSI experts. According to such incorrect information from unknown UK IETF or ETSI expert, the one national decision of the usage of ESSCertID or ESSCertIDv2 presented ESSCertID or ESSCertIDv2 as not useful as mandatory to be included in Qualified Electronic Signatures or AdES based on Qualified Certificates. For that reason I would like to remind that at least two easy realizable attacks are possible: Anybody can use any editor tools for substitution attack e.g. http://lipingshare.com/Asn1Editor/ which is really smart. 1. Attacker (timestamp or electronic document signer) asks two trusted CA for issuing of two certificates with the same key. 2. Attacker asks one CA for revocation of one certificate. 3. If ESSCertID or ESSCertIDv2 is not used, the attacker is able to substitute the signer certificate in timestamp (or signature). 4. The electronic signature is therefore not useable as trusted evidence in some actions. 1. Attacker (timestamp or electronic document signer) asks two trusted CA for issuing of two certificates with the same key but the second certificate is asked and issued after the expiration of the first certificate issued for the same key. 2. If ESSCertID or ESSCertIDv2 is not used, the attacker is able to substitute the signer certificate in timestamp (or signature). 3. The electronic signature is therefore not useable as trusted evidence in some actions. If a certificate is used only as a carrier of public key and the certificate validity is not important, then also ESSCertID or ESSCertIDv2 is not important but in any other situation when the validity has a significant impact on some actions, ESSCertID or ESSCertIDv2 must be used. Another possibility for solving such attacks is to have mandatory rules for CA and registration authorities: The CA must issue a certificate only for the key which was newly generated by CA or registration operators before the certificate creation. Regards, Peter Rybar tel.: +421 2 6869 2163 mob.: +421 902 891 155 fax: +421 2 6869 1701 e-mail: peter.rybar@nbusr.sk e-mail: peterryb@gmail.com _____ From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Tuesday, October 20, 2009 10:10 AM To: denis.pinkas@bull.net; pkix Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-07.txt
- [smime] FW: [pkix] I-D Action:draft-ietf-pkix-rfc… Peter Rybar
- Re: [smime] [pkix] I-D Action:draft-ietf-pkix-rfc… Peter Rybar